summaryrefslogtreecommitdiffstats
path: root/clang/test/Modules/Inputs
Commit message (Collapse)AuthorAgeFilesLines
...
* [ODRHash] Don't hash friend functions.Richard Trieu2018-01-125-0/+47
| | | | | | | | In certain combinations of templated classes and friend functions, the body of friend functions does not get propagated along with function signature. Exclude friend functions for hashing to avoid this case. llvm-svn: 322350
* Test case for r321396Richard Trieu2018-01-0610-0/+63
| | | | | | | | Any hashing for methods should be able to compile this test case without emitting an error. Since the class and method come from the same header from each module, there should be no messages about ODR violations. llvm-svn: 321924
* Reapply r321781: [Modules] Allow modules specified by -fmodule-map-file to ↵Bruno Cardoso Lopes2018-01-0513-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | shadow implicitly found ones When modules come from module map files explicitly specified by -fmodule-map-file= arguments, allow those to override/shadow modules with the same name that are found implicitly by header search. If such a module is looked up by name (e.g. @import), we will always find the one from -fmodule-map-file. If we try to use a shadowed module by including one of its headers report an error. This enables developers to force use of a specific copy of their module to be used if there are multiple copies that would otherwise be visible, for example if they develop modules that are installed in the default search paths. Patch originally by Ben Langmuir, http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151116/143425.html Based on cfe-dev discussion: http://lists.llvm.org/pipermail/cfe-dev/2015-November/046164.html Differential Revision: https://reviews.llvm.org/D31269 rdar://problem/23612102 llvm-svn: 321855
* Revert "[Modules] Allow modules specified by -fmodule-map-file to shadow ↵Bruno Cardoso Lopes2018-01-0413-49/+0
| | | | | | | | | | | implicitly found ones" This reverts r321781 until I fix the leaks pointed out by bots: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/12146 http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/3741 llvm-svn: 321786
* [Modules] Allow modules specified by -fmodule-map-file to shadow implicitly ↵Bruno Cardoso Lopes2018-01-0413-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | found ones When modules come from module map files explicitly specified by -fmodule-map-file= arguments, allow those to override/shadow modules with the same name that are found implicitly by header search. If such a module is looked up by name (e.g. @import), we will always find the one from -fmodule-map-file. If we try to use a shadowed module by including one of its headers report an error. This enables developers to force use of a specific copy of their module to be used if there are multiple copies that would otherwise be visible, for example if they develop modules that are installed in the default search paths. Patch originally by Ben Langmuir, http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151116/143425.html Based on cfe-dev discussion: http://lists.llvm.org/pipermail/cfe-dev/2015-November/046164.html Differential Revision: https://reviews.llvm.org/D31269 rdar://problem/23612102 llvm-svn: 321781
* -gmodules: Emit debug info for implicit module imports via #include.Adrian Prantl2018-01-031-0/+3
| | | | | | | | | | | | When a type is only used as a template parameter and that type is the only type imported from another #include'd module, no skeleton CU for that module is generated, so a consumer doesn't know where to find the type definition. By emitting an import declaration, we can force a skeleton CU to be generated for each imported module. rdar://problem/36266156 llvm-svn: 321754
* [Modules] Change private modules rules and warningsBruno Cardoso Lopes2017-12-2211-0/+22
| | | | | | | | | | | | | | | | We used to advertise private modules to be declared as submodules (Foo.Private). This has proven to not scale well since private headers might carry several dependencies, introducing unwanted content into the main module and often causing dep cycles. Change the canonical way to name it to Foo_Private, forcing private modules as top level ones, and provide warnings under -Wprivate-module to suggest fixes for other private naming. Update documentation to reflect that. rdar://problem/31173501 llvm-svn: 321337
* Modular Codegen: Don't home always_inline functionsDavid Blaikie2017-11-022-0/+6
| | | | | | | | Since they'll likely (not always - if the address is taken, etc) be inlined away, even at -O0, separately provided weak definitions are likely to be unused so skip all of that. llvm-svn: 317279
* [Module map] Introduce a private module re-export directive.Douglas Gregor2017-09-141-0/+9
| | | | | | | | | | | | | Introduce a new "export_as" directive for top-level modules, which indicates that the current module is a "private" module whose symbols will eventually be exported through the named "public" module. This is in support of a common pattern in the Darwin ecosystem where a single public framework is constructed of several private frameworks, with (currently) header duplication and some support from the linker. Addresses rdar://problem/34438420. llvm-svn: 313316
* Revert "[Modules] Prevent #import to reenter header if not building a module."Bruno Cardoso Lopes2017-08-121-6/+0
| | | | | | | This reverts commit r310605. Richard pointed out a better way to achieve this, which I'll post a patch for soon. llvm-svn: 310775
* [modules] Set the lexical DC for dummy tag decls that refer to hiddenAlex Lorenz2017-08-112-0/+15
| | | | | | | | | | | | | | declarations that are made visible after the dummy is parsed and ODR verified Prior to this commit the "(getContainingDC(DC) == CurContext && "The next DeclContext should be lexically contained in the current one.")," assertion failure was triggered during semantic analysis of the dummy tag declaration that was declared in another tag declaration because its lexical context did not point to the outer tag decl. rdar://32292196 llvm-svn: 310706
* [Modules] Prevent #import to reenter header if not building a module.Bruno Cardoso Lopes2017-08-101-0/+6
| | | | | | | | | | When non-modular headers are imported while not building a module but in -fmodules mode, be conservative and preserve the default #import semantic: do not reenter headers. rdar://problem/33745031 llvm-svn: 310605
* Debug Info: Avoid completing class types when a definition is in a module.Adrian Prantl2017-07-241-3/+3
| | | | | | | | | | This patch adds an early exit to CGDebugInfo::completeClassData() when compiling with -gmodules and the to-be-completed type is available in a clang module. rdar://problem/23599990 llvm-svn: 308938
* Update for LLVM IR metadata changes (DIImportedEntity now needs a DIFile).Adrian Prantl2017-07-192-0/+8
| | | | | | | | | <rdar://problem/33357889> https://bugs.llvm.org/show_bug.cgi?id=33822 Differential Revision: https://reviews.llvm.org/D35583 llvm-svn: 308399
* [Modules] Implement ODR-like semantics for tag types in C/ObjCBruno Cardoso Lopes2017-07-014-0/+34
| | | | | | | | | | | | | | | | | | | | | | Allow ODR for ObjC/C in the sense that we won't keep more that one definition around (merge them). However, ensure the decl pass the structural compatibility check in C11 6.2.7/1, for that, reuse the structural equivalence checks used by the ASTImporter. Few other considerations: - Create error diagnostics for tag types mismatches and thread them into the structural equivalence checks. - Note that by doing this we only support redefinition between types that are considered "compatible types" by C. This is mixed approach of the suggestions discussed in http://lists.llvm.org/pipermail/cfe-dev/2017-March/053257.html Differential Revision: https://reviews.llvm.org/D31778 rdar://problem/31909368 llvm-svn: 306918
* [ASTReader] Add test for previous change r306583 / 145692e.Graydon Hoare2017-06-294-0/+12
| | | | | | | | | | | | | | | | | | | | Summary: Add a test for the change to ASTReader that reproduces the logic for consolidating multiple ObjC interface definitions to the case of multiple ObjC protocol definitions. This test is a modified copy of the test that accompanied the original change to interfaces, in 2ba1979. Reviewers: bruno Reviewed By: bruno Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D34788 llvm-svn: 306732
* Track the set of module maps read while building a .pcm file and reload ↵Richard Smith2017-06-295-0/+5
| | | | | | those when preprocessing from that .pcm file. llvm-svn: 306628
* When preprocessing with -frewrite-imports and -fmodule-file=, do not pass allRichard Smith2017-06-264-1/+9
| | | | | | | | | | | modules to preprocessing of nested .pcm files. Making those module files available results in loading more .pcm files than necessary, and potentially in misbehavior if a module makes itself visible during its own compilation (as parts of that module that have not yet been processed would then become visible). llvm-svn: 306320
* Fix crash when an 'import a module' TypoCorrection has its CorrectionDeclsRichard Smith2017-06-052-0/+4
| | | | | | | | | | | | replaced by visible decls. Make sure that all paths through checkCorrectionVisibility set the RequiresImport flag appropriately, so we don't end up using a stale value. Patch by Jorge Gorbe! Differential Revision: https://reviews.llvm.org/D30963 llvm-svn: 304745
* Support lazy stat'ing of files referenced by module maps.Richard Smith2017-06-025-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for a `header` declaration in a module map to specify certain `stat` information (currently, size and mtime) about that header file. This has two purposes: - It removes the need to eagerly `stat` every file referenced by a module map. Instead, we track a list of unresolved header files with each size / mtime (actually, for simplicity, we track submodules with such headers), and when attempting to look up a header file based on a `FileEntry`, we check if there are any unresolved header directives with that `FileEntry`'s size / mtime and perform deferred `stat`s if so. - It permits a preprocessed module to be compiled without the original files being present on disk. The only reason we used to need those files was to get the `stat` information in order to do header -> module lookups when using the module. If we're provided with the `stat` information in the preprocessed module, we can avoid requiring the files to exist. Unlike most `header` directives, if a `header` directive with `stat` information has no corresponding on-disk file the enclosing module is *not* marked unavailable (so that behavior is consistent regardless of whether we've resolved a header directive, and so that preprocessed modules don't get marked unavailable). We could actually do this for all `header` directives: the only reason we mark the module unavailable if headers are missing is to give a diagnostic slightly earlier (rather than waiting until we actually try to build the module / load and validate its .pcm file). Differential Revision: https://reviews.llvm.org/D33703 llvm-svn: 304515
* [Modules] Handle sanitizer feature mismatches when importing modulesVedant Kumar2017-06-012-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes it an error to have a mismatch between the enabled sanitizers in a CU, and in any module being imported into the CU. Only mismatches between non-modular sanitizers are treated as errors. This patch also includes non-modular sanitizers in module hashes, in order to ensure module rebuilds occur when -fsanitize=X is toggled on and off for non-modular sanitizers, and to cut down on module rebuilds when the option is toggled for modular sanitizers. This fixes a longstanding issue with implicit modules and sanitizers, which Duncan originally diagnosed. When building with implicit modules it's possible to hit a scenario where modules are built without -fsanitize=address, and are subsequently imported into CUs with -fsanitize=address enabled. This causes strange failures at runtime. The case Duncan found affects libcxx, since its vector implementation behaves differently when ASan is enabled. Implicit module builds should "just work" when -fsanitize=X is toggled on and off across multiple compiler invocations, which is what this patch does. Differential Revision: https://reviews.llvm.org/D32724 llvm-svn: 304463
* [modules] When we #include a local submodule header that we've already built,Richard Smith2017-05-304-0/+13
| | | | | | | | | | and it has an include guard, produce callbacks for a module import, not for a skipped non-modular header. Fixes -E output when preprocessing a module to list these cases as a module import, rather than suppressing the #include and losing the import side effect. llvm-svn: 304183
* [coroutines] Support "coroutines" feature in module map requires clauseEric Fiselier2017-05-283-1/+14
| | | | | | | | | | | | | | Summary: In order for libc++ to add `<experimental/coroutine>` to its module map, there has to be a feature that can be used to detect if coroutines support is enabled in Clang. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D33538 llvm-svn: 304107
* Revert "[coroutines] Support "coroutines" feature in module map requires clause"Eric Fiselier2017-05-273-14/+1
| | | | | | This reverts commit r304054. llvm-svn: 304057
* [coroutines] Support "coroutines" feature in module map requires clauseEric Fiselier2017-05-273-1/+14
| | | | | | | | | | | | | | Summary: In order for libc++ to add `<experimental/coroutine>` to its module map, there has to be a feature that can be used to detect if coroutines support is enabled in Clang. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D33538 llvm-svn: 304054
* [Modules] Fix overly conservative assertion for import diagnosticBruno Cardoso Lopes2017-05-232-0/+11
| | | | | | | | | | | | | | | | We currenltly assert when want to diagnose a missing import and the decl in question is already visible. It turns out that the decl in question might be visible because another decl from the same module actually made the module visible in a previous error diagnostic. Remove the assertion and avoid re-exporting the module if it's already visible. rdar://problem/27975402 Differential Revision: https://reviews.llvm.org/D32828 llvm-svn: 303705
* [Lexer] Ensure that the token is not an annotation token whenAlex Lorenz2017-05-172-0/+7
| | | | | | | | | | | retrieving the identifer info for an Objective-C keyword This commit fixes an assertion that's triggered in getIdentifier when the token is an annotation token. rdar://32225463 llvm-svn: 303246
* [modules] When creating a declaration, cache its owning module immediatelyRichard Smith2017-05-172-1/+14
| | | | | | | | | | | | | | | rather than waiting until it's queried. Currently this is only applied to local submodule visibility mode, as we don't yet allocate storage for the owning module in non-local-visibility modules compilations. This reinstates r302965, reverted in r303037, with a fix for the reported crash, which occurred when reparenting a local declaration to be a child of a hidden imported declaration (specifically during template instantiation). llvm-svn: 303224
* Module Debug Info: Emit namespaced C++ forward decls in the correct module.Adrian Prantl2017-05-113-0/+14
| | | | | | | | | | | | The AST merges NamespaceDecls, but for module debug info it is important to put a namespace decl (or rather its children) into the correct (sub-)module, so we need to use the parent module of the decl that triggered this namespace to be serialized as a second key when looking up DINamespace nodes. rdar://problem/29339538 llvm-svn: 302840
* [Sema] Improve redefinition errors pointing to the same headerBruno Cardoso Lopes2017-05-114-0/+30
| | | | | | | | | | | | | | | | | | Diagnostics related to redefinition errors that point to the same header file do not provide much information that helps users fixing the issue. - In the modules context, it usually happens because of non modular includes. - When modules aren't involved it might happen because of the lack of header guards. Enhance diagnostics in these scenarios. Differential Revision: https://reviews.llvm.org/D28832 rdar://problem/31669175 llvm-svn: 302765
* [Modules] Allow umbrella frameworks to define private submodules for ↵Bruno Cardoso Lopes2017-05-0910-0/+34
| | | | | | | | | | | | subframeworks In r298391 we fixed the umbrella framework model to work when submodules named "Private" are used. This complements the work by allowing the umbrella framework model to work in general. rdar://problem/31790067 llvm-svn: 302491
* Add #pragma clang module begin/end pragmas and generate them when ↵Richard Smith2017-05-042-1/+3
| | | | | | | | | | | | | | preprocessing a module. These pragmas are intended to simulate the effect of entering or leaving a file with an associated module. This is not completely implemented yet: declarations between the pragmas will not be attributed to the correct module, but macro visibility is already functional. Modules named by #pragma clang module begin must already be known to clang (in some module map that's either loaded or on the search path). llvm-svn: 302098
* New file missed from r301846.Richard Smith2017-05-011-0/+1
| | | | llvm-svn: 301847
* Fix initial diagnostic state setup for an explicit module with no diagnostic ↵Richard Smith2017-05-011-0/+4
| | | | | | | | | | | | pragmas. If a file has no diagnostic pragmas, we build its diagnostic state lazily, but in this case we never set up the root state to be the diagnostic state in which the module was originally built, so the diagnostic flags for files in the module with no diagnostic pragmas were incorrectly based on the user of the module rather than the diagnostic state when the module was built. llvm-svn: 301846
* [Modules] Improve diagnostics for incomplete umbrellaBruno Cardoso Lopes2017-04-276-0/+14
| | | | | | | | | | | | | One of the -Wincomplete-umbrella warnings diagnoses when a header is present in the directory but it's not present in the umbrella header. Currently, this warning only happens on top level modules; any submodule using an umbrella header does not get this warning. Fix that by also considering the submodules. Differential Revision: https://reviews.llvm.org/D32576 rdar://problem/22623686 llvm-svn: 301597
* [Modules] Fix a crash-on-invalid with overloaded functionsBruno Cardoso Lopes2017-04-262-0/+6
| | | | | | | | | | Do not add an overload if the function doesn't have a prototype; this can happen if, for instance, a misplaced/malformed call site is considered like a declaration for recovery purposes. rdar://problem/31306325 llvm-svn: 301453
* [Modules][ObjC] Check definition from canonical decl on designated initializersBruno Cardoso Lopes2017-04-265-0/+22
| | | | | | | | | | Use definition from canonical decl when checking for designated initializers. This is necessary since deserialization of a interface might reuse the definition from the canonical one (see r281119). rdar://problem/29360655 llvm-svn: 301382
* [modules] Properly look up the owning module for an instantiation of a ↵Richard Smith2017-04-212-0/+20
| | | | | | | | | | | | | | | merged template. When looking for the template instantiation pattern of a templated entity, consistently select the definition of the pattern if there is one. This means we'll pick the same owning module when we start instantiating a template that we'll later pick when determining which modules are visible during that instantiation. This reinstates r300650, reverted in r300659, with a fix for a regression reported by Chandler after commit. llvm-svn: 300938
* Revert r300653 and r300650. The underlying commit fixes one issue withChandler Carruth2017-04-191-8/+0
| | | | | | | | | | modules but exposes much more widespread issues. Example and more information is on the review thread for r300650. Original commit summary: [modules] Properly look up the owning module for an instantiation of a merged template. llvm-svn: 300659
* [modules] Properly look up the owning module for an instantiation of a ↵Richard Smith2017-04-191-0/+8
| | | | | | | | | | | | merged template. When looking for the template instantiation pattern of a templated entity, consistently select the definition of the pattern if there is one. This means we'll pick the same owning module when we start instantiating a template that we'll later pick when determining which modules are visible during that instantiation. llvm-svn: 300650
* Modules: Do not serialize #pragma pack stateDuncan P. N. Exon Smith2017-04-153-24/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The modules side of r299226, which serializes #pragma pack state, doesn't work well. The main purpose was to make -include and -include-pch match semantics (the PCH side). We also started serializing #pragma pack in PCMs, in the hopes of making modules and non-modules builds more consistent. But consider: $ cat a.h $ cat b.h #pragma pack(push, 2) $ cat module.modulemap module M { module a { header "a.h" } module b { header "b.h" } } $ cat t.cpp #include "a.h" #pragma pack(show) As of r299226, the #pragma pack(show) gives "2", even though we've only included "a.h". - With -fmodules-local-submodule-visibility, this is clearly wrong. We should get the default state (8 on x86_64). - Without -fmodules-local-submodule-visibility, this kind of matches how other things work (as if include-the-whole-module), but it's still really terrible, and it doesn't actually make modules and non-modules builds more consistent. This commit disables the serialization for modules, essentially a partial revert of r299226. Going forward: 1. Having this #pragma pack stuff escape is terrible design (or, more often, a horrible bug). We should prioritize adding warnings (maybe -Werror by default?). 2. If we eventually reintroduce this for modules, it should only apply to -fmodules-local-submodule-visibility, and it should be tracked on a per-submodule basis. llvm-svn: 300380
* Modular Codegen: Include testing for inline asm as well as some commentary ↵David Blaikie2017-04-121-0/+2
| | | | | | on the implementaiton choice. llvm-svn: 300106
* Modular Codegen: Separate flags for function and debug info supportDavid Blaikie2017-04-123-0/+10
| | | | | | | | | | This allows using and testing these two features separately. (noteably, debug info is, so far as I know, always a win (basically). But function modular codegen is currently a loss for highly optimized code - where most of the linkonce_odr definitions are optimized away, so providing weak_odr definitions is only overhead) llvm-svn: 300104
* Serialization: Simulate -Werror settings in implicit modulesDuncan P. N. Exon Smith2017-04-122-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | r293123 started serializing diagnostic pragma state for modules. This makes the serialization work properly for implicit modules. An implicit module build (using Clang's internal build system) uses the same PCM file location for different `-Werror` levels. E.g., if a TU has `-Werror=format` and tries to load a PCM built without `-Werror=format`, a new PCM will be built in its place (and the new PCM should have the same signature, since r297655). In the other direction, if a TU does not have `-Werror=format` and tries to load a PCM built with `-Werror=format`, it should "just work". The idea is to evolve the PCM toward the strictest -Werror flags that anyone tries. r293123 started serializing the diagnostic pragma state for each PCM. Since this encodes the -Werror settings at module-build time, it breaks the implicit build model. This commit filters the diagnostic state in order to simulate the current compilation's diagnostic settings. Firstly, it ignores the module's serialized first diagnostic state, replacing it with the state from this compilation's command-line. Secondly, if a pragma warning was upgraded to error/fatal when generating the PCM (e.g., due to `-Werror` on the command-line), it checks whether it should still be upgraded in its current context. llvm-svn: 300025
* Modular Codegen: Support homing debug info for types in modular objectsDavid Blaikie2017-04-111-2/+8
| | | | | | | | | Matching the function-homing support for modular codegen. Any type implicitly (implicit template specializations) or explicitly defined in a module is attached to that module's object file and omitted elsewhere (only a declaration used if necessary for references). llvm-svn: 299987
* Modular Codegen: Add/use a bit in serialized function definitions to track ↵David Blaikie2017-04-114-0/+40
| | | | | | | | | | | | | | | | | | | | | whether they are the subject of modular codegen Some decls are created not where they are written, but in other module files/users (implicit special members and function template implicit specializations). To correctly identify them, use a bit next to the definition to track the modular codegen property. Discussed whether the module file bit could be omitted in favor of reconstituting from the modular codegen decls list - best guess today is that the efficiency improvement of not having to deserialize the whole list whenever any function is queried by a module user is worth it for the small size increase of this redundant (list + bit-on-def) representation. Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D29901 llvm-svn: 299982
* [Modules][PCH] Serialize #pragma packAlex Lorenz2017-03-314-0/+29
| | | | | | | | | | | This patch serializes the state of #pragma pack. It preserves the state of the pragma from a PCH/from modules in a file that uses that PCH/those modules. rdar://21359084 Differential Revision: https://reviews.llvm.org/D31241 llvm-svn: 299226
* [Modules] Find PrivateHeaders when looking into subframeworksBruno Cardoso Lopes2017-03-2110-0/+33
| | | | | | | | | Fix the current parsing of subframeworks in modulemaps to lookup for headers based on whether they are frameworks. rdar://problem/30563982 llvm-svn: 298391
* Avoid these headers looking like the same file on a content-addressed file ↵Richard Smith2017-03-202-0/+2
| | | | | | system. llvm-svn: 298300
* Reapply "Modules: Cache PCMs in memory and avoid a use-after-free"Duncan P. N. Exon Smith2017-03-207-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit r298185, effectively reapplying r298165, after fixing the new unit tests (PR32338). The memory buffer generator doesn't null-terminate the MemoryBuffer it creates; this version of the commit informs getMemBuffer about that to avoid the assert. Original commit message follows: ---- Clang's internal build system for implicit modules uses lock files to ensure that after a process writes a PCM it will read the same one back in (without contention from other -cc1 commands). Since PCMs are read from disk repeatedly while invalidating, building, and importing, the lock is not released quickly. Furthermore, the LockFileManager is not robust in every environment. Other -cc1 commands can stall until timeout (after about eight minutes). This commit changes the lock file from being necessary for correctness to a (possibly dubious) performance hack. The remaining benefit is to reduce duplicate work in competing -cc1 commands which depend on the same module. Follow-up commits will change the internal build system to continue after a timeout, and reduce the timeout. Perhaps we should reconsider blocking at all. This also fixes a use-after-free, when one part of a compilation validates a PCM and starts using it, and another tries to swap out the PCM for something new. The PCMCache is a new type called MemoryBufferCache, which saves memory buffers based on their filename. Its ownership is shared by the CompilerInstance and ModuleManager. - The ModuleManager stores PCMs there that it loads from disk, never touching the disk if the cache is hot. - When modules fail to validate, they're removed from the cache. - When a CompilerInstance is spawned to build a new module, each already-loaded PCM is assumed to be valid, and is frozen to avoid the use-after-free. - Any newly-built module is written directly to the cache to avoid the round-trip to the filesystem, making lock files unnecessary for correctness. Original patch by Manman Ren; most testcases by Adrian Prantl! llvm-svn: 298278
OpenPOWER on IntegriCloud