summaryrefslogtreecommitdiffstats
path: root/clang/test/Modules/Inputs
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Reinstate r281429, reverted in r281452, with a fix for its mishandling ofRichard Smith2016-10-138-1/+38
| | | | | | | | | compiles without -fmodules-local-submodule-visibility. Original commit message: [modules] When merging one definition into another, propagate the list of re-exporting modules from the discarded definition to the retained definition. llvm-svn: 284176
* Module: emit initializers for C/ObjC after r276159.Manman Ren2016-10-132-0/+7
| | | | | | | | | In r276159, we started to defer emitting initializers for VarDecls, but forgot to add the initializers for non-C++ language. rdar://28740482 llvm-svn: 284142
* Revert r284008. This is us to fail to instantiate static data members in someRichard Smith2016-10-126-36/+0
| | | | | | cases. I'm working on reducing a testcase. llvm-svn: 284081
* Reinstate r283887 and r283882.Vassil Vassilev2016-10-126-0/+36
| | | | | | | | | | | Original message: "[modules] PR28752: Do not instantiate variable declarations which are not visible. https://reviews.llvm.org/D24508 Patch developed in collaboration with Richard Smith!" llvm-svn: 284008
* Module: for ObjectiveC, be consistent when checking hidden decls.Manman Ren2016-10-114-0/+21
| | | | | | | | | In MatchAllMethodDeclarations, when checking a hidden decl, be sure to allow hidden when searching for methods. rdar://28699972 llvm-svn: 283943
* Revert r283887 and r283882, until the issue is understood and fixed.Vassil Vassilev2016-10-116-36/+0
| | | | llvm-svn: 283890
* [modules] PR28752: Do not instantiate variable declarations which are not ↵Vassil Vassilev2016-10-116-0/+36
| | | | | | | | | | visible. https://reviews.llvm.org/D24508 Patch developed in collaboration with Richard Smith! llvm-svn: 283882
* [modules] Be sure to emit local specializations of imported templates, even ifRichard Smith2016-10-064-0/+9
| | | | | | | | | | | the resulting specialization is not referenced by the rest of the AST. This both avoids performing unnecessary reinstantiations in downstream users of the AST file and fixes a bug (breaking modules self-host right now) where we would sometimes fail to emit a definition of a class template specialization if we imported just a declaration of it from elsewhere (see new testcase for reduced example). llvm-svn: 283489
* ObjectiveC: fix a seg fault when deserialing redeclaration of ObjCMethodDecl.Manman Ren2016-10-031-0/+4
| | | | | | | | | | | | | | | The deserialization of redeclartion can cause seg fault since getCanonicalDecl of the redeclaration returns the lookup result on the ObjCContainerDecl, which can be null if FindExternalVisibleDeclsByName is not done updating the lookup results. The fix is to return the redeclaration itself as the canonical decl. Note that the handling for redeclaration of ObjCMethodDecl is not in line with other redeclarables. rdar://28488466 llvm-svn: 283145
* Revert "[modules] When merging one definition into another, propagate the ↵Eric Liu2016-09-143-8/+0
| | | | | | | | list of re-exporting modules from the discarded definition to the retained definition." This reverts commit r281429. llvm-svn: 281452
* [modules] When merging one definition into another, propagate the list ofRichard Smith2016-09-143-0/+8
| | | | | | re-exporting modules from the discarded definition to the retained definition. llvm-svn: 281429
* Fix interaction between serialization and c++1z feature.Richard Trieu2016-09-132-0/+4
| | | | | | | | In c++1z, static_assert is not required to have a StringLiteral message, where previously it was required. Update the AST Reader to be able to handle a null StringLiteral. llvm-svn: 281286
* Add a couple of test files missed in r281258.Richard Smith2016-09-122-0/+10
| | | | llvm-svn: 281259
OpenPOWER on IntegriCloud