summaryrefslogtreecommitdiffstats
path: root/clang/test/Modules/Inputs
Commit message (Collapse)AuthorAgeFilesLines
* [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
* Revert "Modules: Cache PCMs in memory and avoid a use-after-free"Renato Golin2017-03-187-25/+0
| | | | | | This reverts commit r298165, as it broke the ARM builds. llvm-svn: 298185
* Modules: Cache PCMs in memory and avoid a use-after-freeDuncan P. N. Exon Smith2017-03-177-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: 298165
* Canonicalize the path provided by -fmodules-cache-path.Adrian Prantl2017-03-146-0/+34
| | | | | | | | | | | This fixes lookup mismatches that could happen when the module cache path contained a '/./' component. <rdar://problem/30413458> Differential Revision: https://reviews.llvm.org/D30915 llvm-svn: 297790
* Take into account C++17's noexcept function types during merging -- it shouldRichard Smith2017-03-082-0/+4
| | | | | | | be possible to merge a declaration with an unresolved function type against one with a resolved function type. llvm-svn: 297316
* [modules] Add missing test from r297030.Vassil Vassilev2017-03-062-0/+6
| | | | llvm-svn: 297037
* [Test] NFC: Fixed typo in commentsCharles Li2017-03-011-2/+2
| | | | | | Changed "declerations" to "declarations" llvm-svn: 296648
* [Test] Make Lit tests C++11 compatible #10Charles Li2017-02-241-0/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D21626 llvm-svn: 296193
* Represent pass_object_size attrs in ExtParameterInfoGeorge Burgess IV2017-02-241-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The goal of this is to fix a bug in modules where we'd merge FunctionDecls that differed in their pass_object_size attributes. Since we can overload on the presence of pass_object_size attributes, this behavior is incorrect. We don't represent `N` in `pass_object_size(N)` as part of ExtParameterInfo, since it's an error to overload solely on the value of N. This means that we have a bug if we have two modules that declare functions that differ only in their pass_object_size attrs, like so: // In module A, from a.h void foo(char *__attribute__((pass_object_size(0)))); // In module B, from b.h void foo(char *__attribute__((pass_object_size(1)))); // In module C, in main.c #include "a.h" #include "b.h" At the moment, we'll merge the foo decls, when we should instead emit a diagnostic about an invalid overload. We seem to have similar (silent) behavior if we overload only on the return type of `foo` instead; I'll try to find a good place to put a FIXME (or I'll just file a bug) soon. This patch also fixes a bug where we'd not output the proper extended parameter info for declarations with pass_object_size attrs. llvm-svn: 296076
* [ObjC][Modules] Don't perform property lookup in hidden class extensionsAlex Lorenz2017-02-221-0/+5
| | | | | | rdar://30603803 llvm-svn: 295903
* [Modules] Consider enable_if attrs in isSameEntity.George Burgess IV2017-02-152-0/+19
| | | | | | | | | | | | | | Two functions that differ only in their enable_if attributes are considered overloads, so we should check for those when we're trying to figure out if two functions are mergeable. We need to do the same thing for pass_object_size, as well. Looks like that'll be a bit less trivial, since we sometimes do these merging checks before we have pass_object_size attributes available (see the merge checks in ASTDeclReader::VisitFunctionDecl that happen before we read parameters, and merge checks in calls to ReadDeclAs<>()). llvm-svn: 295252
* Initialize builtins during modular codegenDavid Blaikie2017-02-086-9/+14
| | | | llvm-svn: 294512
* [PCH] Fix a regression when PCH is used with -fmodulesBruno Cardoso Lopes2017-02-078-0/+19
| | | | | | | | | | | | | | | | | Following up on r291465 after a regression in r276159. When we use -fmodule-name=X while building a PCH, modular headers in X will be textually included and the compiler knows that we are not building module X, so don't serialize such headers in the PCH as being part of a module, because at this point they are not. This was causing subtle bugs and malformed AST crashes, for instance, when using the PCH in subsequent compiler invocation with -fmodules, the HFI for a modular header would map to the PCH, which would force a module load of and unexistent module ID. rdar://problem/30171164 llvm-svn: 294361
* Prototype of modules codegenDavid Blaikie2017-01-305-0/+16
| | | | | | | | | | | | | | | | | | | | | First pass at generating weak definitions of inline functions from module files (& skipping (-O0) or emitting available_externally (optimizations) definitions where those modules are used). External functions defined in modules are emitted into the modular object file as well (this may turn an existing ODR violation (if that module were imported into multiple translations) into valid/linkable code). Internal symbols (static functions, for example) are not correctly supported yet. The symbol will be produced, internal, in the modular object - unreferenceable from the users. Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D28845 llvm-svn: 293456
* [modules] Additional tests.Richard Smith2017-01-2611-0/+31
| | | | llvm-svn: 293223
* Add files forgotten in r293219.Richard Smith2017-01-262-0/+3
| | | | llvm-svn: 293222
* [modules] When reading / writing a typedef that is a name for linkage forRichard Smith2017-01-262-0/+5
| | | | | | | | | | | | | | another declaration, ensure we actually serialize / deserialize that declaration. Before this patch, if another copy of the typedef were merged with the parsed version, we would emit type information referring to the merged version and consequently emit nothing about the parsed anonymous struct. This resulted in us losing information, particularly the visible merged module set for the parsed definition. Force that information to be emitted and to be loaded when the typedef is used. llvm-svn: 293219
* Remove and replace DiagStatePoint tracking and lookup data structure.Richard Smith2017-01-261-0/+10
| | | | | | | | | | | | | | | | | | | | | | | Rather than storing a single flat list of SourceLocations where the diagnostic state changes (in source order), we now store a separate list for each FileID in which there is a diagnostic state transition. (State for other files is built and cached lazily, on demand.) This has two consequences: 1) We can now sensibly support modules, and properly track the diagnostic state for modular headers (this matters when, for instance, triggering instantiation of a template defined within a module triggers diagnostics). 2) It's much faster than the old approach, since we can now just do a binary search on the offsets within the FileID rather than needing to call isBeforeInTranslationUnit to determine source order (which is surprisingly slow). For some pathological (but real world) files, this reduces total compilation time by more than 10%. For now, the diagnostic state points for modules are loaded eagerly. It seems feasible to defer this until diagnostic state information for one of the module's files is needed, but that's not part of this patch. llvm-svn: 293123
* [Modules] Fix misleading warning about missing textual header in umbrella headerBruno Cardoso Lopes2017-01-125-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | When a textual header is present inside a umbrella dir but not in the header, we get the misleading warning: warning: umbrella header for module 'FooFramework' does not include header 'Baz_Private.h' The module map in question: framework module FooFramework { umbrella header "FooUmbrella.h" export * module * { export * } module Private { textual header "Baz_Private.h" } } Fix this by taking textual headers into account. llvm-svn: 291794
* PR31469: Don't add friend template class decls to redecl chain in dependent ↵Vassil Vassilev2017-01-124-0/+25
| | | | | | | | | | | | | | | | | contexts. Fixes a crash in modules where the template class decl becomes the most recent decl in the redeclaration chain and forcing the template instantiator try to instantiate the friend declaration, rather than the template definition. In practice, A::list<int> produces a TemplateSpecializationType A::__1::list<int, allocator<type-parameter-0-0> >' failing to replace to subsitute the default argument to allocator<int>. Kudos Richard Smith (D28399). llvm-svn: 291753
* Module: Do not add any link flags when an implementation TU of a module importsManman Ren2017-01-112-0/+5
| | | | | | | | | | | a header of that same module. This fixes a regression caused by r280409. rdar://problem/29930553 This is an updated version for r291628 (which was reverted in r291688). llvm-svn: 291689
* This reverts r291628. As suggested by Richard, we can simplyManman Ren2017-01-112-5/+0
| | | | | | | | filter out the implicilty imported modules at CodeGen instead of removing the implicit ImportDecl when an implementation TU of a module imports a header of that same module. llvm-svn: 291688
* [Modules] Support #import when entering files with modulesBruno Cardoso Lopes2017-01-1117-1/+101
| | | | | | | | | | | | Textual headers and builtins that are #import'd from different modules should get re-entered when these modules are independent from each other. Differential Revision: https://reviews.llvm.org/D26267 rdar://problem/25881934 llvm-svn: 291644
* Module: Do not create Implicit ImportDecl for module X if weManman Ren2017-01-112-0/+5
| | | | | | | | | are building an implemenation of module X. This fixes a regression caused by r280409. rdar://problem/29930553 llvm-svn: 291628
* PCH: fix a regression that reports a module is defined in both pch and pcm.Manman Ren2017-01-096-0/+14
| | | | | | | | | | | | | | | | | In r276159, we started to say that a module X is defined in a pch if we specify -fmodule-name when building the pch. This caused a regression that reports module X is defined in both pch and pcm if we generate the pch with -fmodule-name=X and then in a separate clang invocation, we include the pch and also import X.pcm. This patch adds an option CompilingPCH similar to CompilingModule. When we use -fmodule-name=X while building a pch, modular headers in X will be textually included and the compiler knows that we are not building module X, so we don't put module X in SUBMODULE_DEFINITION of the pch. Differential Revision: http://reviews.llvm.org/D28415 llvm-svn: 291465
* [modules] Handle modules with nonstandard names in module.private.modulemapsGraydon Hoare2016-12-214-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The module system supports accompanying a primary module (say Foo) with an auxiliary "private" module (defined in an adjacent module.private.modulemap file) that augments the primary module when associated private headers are available. The feature is intended to be used to augment the primary module with a submodule (say Foo.Private), however some users in the wild are choosing to augment the primary module with an additional top-level module with a "similar" name (in all cases so far: FooPrivate). This "works" when a user of the module initially imports a private header, such as '#import "Foo/something_private.h"' since the Foo import winds up importing FooPrivate in passing. But if the import is subsequently recorded in a PCH file, reloading the PCH will fail to validate because of a cross-check that attempts to find the module.modulemap (or module.private.modulemap) using HeaderSearch algorithm, applied to the "FooPrivate" name. Since it's stored in Foo.framework/Modules, not FooPrivate.framework/Modules, the check fails and the PCH is rejected. This patch adds a compensatory workaround in the HeaderSearch algorithm when searching (and failing to find) a module of the form FooPrivate: the name used to derive filesystem paths is decoupled from the module name being searched for, and if the initial search fails and the module is named "FooPrivate", the filesystem search name is altered to remove the "Private" suffix, and the algorithm is run a second time (still looking for a module named FooPrivate, but looking in directories derived from Foo). Accompanying this change is a new warning that triggers when a user loads a module.private.modulemap that defines a top-level module with a different name from the top-level module defined in its adjacent module.modulemap. Reviewers: doug.gregor, manmanren, bruno Subscribers: bruno, cfe-commits Differential Revision: https://reviews.llvm.org/D27852 llvm-svn: 290219
* [modules] Use the "redundant #include" diagnostic rather than the "moduleRichard Smith2016-12-061-1/+4
| | | | | | | | import can't appear here" diagnostic if an already-visible module is textually entered (because we have the module map but not the AST file) within a function/namespace scope. llvm-svn: 288737
* [modules] Mark deleted functions as implicitly inline to allow mergingEric Fiselier2016-10-311-0/+1
| | | | | | | | | | | | Summary: When merging definitions with ModulesLocalVisibility enabled it's important to make deleted definitions implicitly inline, otherwise they'll be diagnosed as a redefinition. Reviewers: silvas, manmanren, rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D26143 llvm-svn: 285655
* [Modules] Add testcase for builtins used in umbrella headersBruno Cardoso Lopes2016-10-285-0/+42
| | | | | | | | | | | | | | This used to work before r284797 + r285152, which exposed something interesting; some users include builtins from umbrella headers. Clang should emit a warning to warn users this is not a good practice and umbrella headers shouldn't get the implicitly-add-the-builtin-version behavior for builtin header names. While we're not there, add the testcase to represent the way it currently works. llvm-svn: 285377
* [modules] PR28812: Modules can return duplicate field decls.Vassil Vassilev2016-10-264-0/+19
| | | | | | | | | | | | | If two modules contain duplicate class definitions the lookup result can contain more than 2 elements. Sift the lookup results until we find a field decl. It is not necessary to do ODR checks in place as they done elsewhere. This should fix issues when compiling with libstdc++ 5.2 and 6.2. Patch developed in collaboration with Richard Smith! llvm-svn: 285184
* [modules] Fix assert if multiple update records provide a definition for aRichard Smith2016-10-263-0/+9
| | | | | | class template specialization and that specialization has attributes. llvm-svn: 285160
* Treat module headers wrapped by our builtin headers as implicitly being textualRichard Smith2016-10-262-2/+1
| | | | | | | | | | headers. We previously got this check backwards and treated the wrapper header as being textual. This is important because our wrapper headers sometimes inject macros into the system headers that they #include_next, and sometimes replace them entirely. llvm-svn: 285152
* Remove non-existing file from modulemap.Benjamin Kramer2016-10-211-1/+0
| | | | | | This picked up a builtin header if it happened to be available. llvm-svn: 284815
* [Modules] Add 'no_undeclared_includes' module map attributeBruno Cardoso Lopes2016-10-2120-1/+97
| | | | | | | | | | | | | The 'no_undeclared_includes' attribute should be used in a module to tell that only non-modular headers and headers from used modules are accepted. The main motivation behind this is to prevent dep cycles between system libraries (such as darwin) and libc++. Patch by Richard Smith! llvm-svn: 284797
* [modules] Do not report missing definitions of demoted constexpr variable ↵Vassil Vassilev2016-10-194-0/+31
| | | | | | | | | | | | | | templates. This is a followup to regression introduced in r284284. This should fix our libstdc++ modules builds. https://reviews.llvm.org/D25678 Reviewed by Richard Smith! llvm-svn: 284577
* Revert "Reinstate r281429, reverted in r281452, with a fix for its ↵Benjamin Kramer2016-10-178-38/+1
| | | | | | | | | mishandling of" This reverts commit r284176. It still marks some modules as invisible that should be visible. Will follow up with the author with a test case. llvm-svn: 284382
* Reinstate r284008 reverted in r284081, with two fixes:Richard Smith2016-10-146-0/+41
| | | | | | | | | | | | | | | | | | | 1) Merge and demote variable definitions when we find a redefinition in MergeVarDecls, not only when we find one in AddInitializerToDecl (we only reach the second case if it's the addition of the initializer itself that converts an existing declaration into a definition). 2) When rebuilding a redeclaration chain for a variable, if we merge two definitions together, mark the definitions as merged so the retained definition is made visible whenever the demoted definition would have been. Original commit message (from r283882): [modules] PR28752: Do not instantiate variable declarations which are not visible. Original patch by Vassil Vassilev! Changes listed above are mine. llvm-svn: 284284
* Module: emit initializers in submodules when importing the parent module.Manman Ren2016-10-141-1/+4
| | | | | | | | | When importing the parent module, module initializers in submodules should be emitted. rdar://28740482 llvm-svn: 284263
OpenPOWER on IntegriCloud