summaryrefslogtreecommitdiffstats
path: root/clang/test/Modules
Commit message (Collapse)AuthorAgeFilesLines
...
* [modules] If we re-enter a submodule from within itself (when submoduleRichard Smith2015-05-214-0/+31
| | | | | | | | | | visibility is enabled) or leave and re-enter it, restore the macro and module visibility state from last time we were in that submodule. This allows mutually-#including header files to stand a chance at being modularized with local visibility enabled. llvm-svn: 237871
* [modules] Support merging a parsed default argument with an imported hidden ↵Richard Smith2015-05-201-1/+2
| | | | | | one for non-type and template template parameters too. llvm-svn: 237815
* [modules] Support merging a parsed default function/template argument with ↵Richard Smith2015-05-201-0/+2
| | | | | | an imported but hidden one. llvm-svn: 237814
* Revert r237609 for now.Richard Smith2015-05-191-3/+3
| | | | | | | | | | | | glibc's headers use __need_* macros to selectively export parts of themselves to each other. This requires us to enter those files repeatedly when building a glibc module. This can be unreverted once we have a better mechanism to deal with that non-modular aspect of glibc (possibly some way to mark a header as "textual if this macro is defined"). llvm-svn: 237718
* [modules] Support for merging a parsed definition of a static data member of ↵Richard Smith2015-05-191-0/+2
| | | | | | a class template into an imported but hidden definition. llvm-svn: 237647
* [modules] Support for merging a parsed class template specialization ↵Richard Smith2015-05-181-0/+5
| | | | | | definition into an imported but hidden definition. llvm-svn: 237612
* [modules] When a file is listed as a non-textual header in a module map, don'tRichard Smith2015-05-181-3/+3
| | | | | | | | | | enter it more than once, even if it doesn't have #include guards -- we already know that it is intended to have the same effect every time it's included, and it's already had that effect. This particularly helps with local submodule visibility builds, where the include guard macro may not be visible in the includer, but will become visible the moment we enter the included file. llvm-svn: 237609
* [modules] If we see a #include that maps to a module, but use of precompiled ↵Richard Smith2015-05-182-1/+2
| | | | | | modules is disabled, track submodule visibility anyway if -fmodules-local-submodule-visibility is enabled. This, in effect, gives modules semantics but without precompilation. llvm-svn: 237550
* [modules] Add local submodule visibility support for declarations.Richard Smith2015-05-157-2/+28
| | | | | | | | | | | | With this change, enabling -fmodules-local-submodule-visibility results in name visibility rules being applied to submodules of the current module in addition to imported modules (that is, names no longer "leak" between submodules of the same top-level module). This also makes it much safer to textually include a non-modular library into a module: each submodule that textually includes that library will get its own "copy" of that library, and so the library becomes visible no matter which including submodule you import. llvm-svn: 237473
* [modules] Suport for merging a parsed enum definition into an existing ↵Richard Smith2015-05-071-0/+7
| | | | | | imported but not visible definition. llvm-svn: 236690
* Fix public-private.modulemap test case to clear the cache on every run.Peter Collingbourne2015-05-061-2/+3
| | | | llvm-svn: 236655
* Switch PPCallbacks to take the new MacroDefinition instead of ↵Richard Smith2015-05-041-0/+1
| | | | | | MacroDirective*, in order to preserve full information on module macro expansion. llvm-svn: 236404
* [modules] If a module #includes a modular header that #undef's its macro, itRichard Smith2015-05-024-0/+23
| | | | | | | | should not export the macro. ... at least, not unless we have local submodule visibility enabled. llvm-svn: 236369
* [modules] Add -fmodules-local-submodule-visibility flag.Richard Smith2015-05-014-16/+55
| | | | | | | | | | | | | | | This flag specifies that the normal visibility rules should be used even for local submodules (submodules of the currently-being-built module). Thus names will only be visible if a header / module that declares them has actually been included / imported, and not merely because a submodule that happened to be built earlier declared those names. This also removes the need to modularize bottom-up: textually-included headers will be included into every submodule that includes them, since their include guards will not leak between modules. So far, this only governs visibility of macros, not of declarations, so is not ready for real use yet. llvm-svn: 236350
* [modules] Stop trying to fake up a linear MacroDirective history.Richard Smith2015-04-291-0/+1
| | | | | | | | | | | | | | Modules builds fundamentally have a non-linear macro history. In the interest of better source fidelity, represent the macro definition information faithfully: we have a linear macro directive history within each module, and at any point we have a unique "latest" local macro directive and a collection of visible imported directives. This also removes the attendent complexity of attempting to create a correct MacroDirective history (which we got wrong in the general case). No functionality change intended. llvm-svn: 236176
* [modules] Properly attribute macros to modules if they're in a file ↵Richard Smith2015-04-233-0/+6
| | | | | | textually included into a file in the module. llvm-svn: 235661
* [modules] Allow a function template definition if we have a pre-existing but ↵Richard Smith2015-03-272-6/+27
| | | | | | not visible definition of the same template. llvm-svn: 233430
* Add file forgotten from r233420.Richard Smith2015-03-271-0/+1
| | | | llvm-svn: 233425
* [modules] When merging class definitions, make the retained definition visibleRichard Smith2015-03-275-19/+19
| | | | | | | | if the merged definition is visible, and perform lookups into all merged copies of the definition (not just for special members) so that we can complete the redecl chains for members of the class. llvm-svn: 233420
* [modules] Allow a function to be redefined if the old definition is not visible.Richard Smith2015-03-272-3/+9
| | | | llvm-svn: 233407
* [modules] Handle defining a tag with a typedef name for linkage purposes on ↵Richard Smith2015-03-272-0/+9
| | | | | | top of an existing imported-but-not-visible definition. llvm-svn: 233345
* [modules] Handle defining a class template on top of an existing ↵Richard Smith2015-03-272-2/+27
| | | | | | imported-but-not-visible definition. llvm-svn: 233341
* [Modules] Fix a sneaky bug in r233249 where we would look for implicitChandler Carruth2015-03-262-0/+9
| | | | | | | | | | | | | | | | | constructors in the current lexical context even though name lookup found them via some other context merged into the redecl chain. This can only happen for implicit constructors which can only have the name of the type of the current context, so we can fix this by simply *always* merging those names first. This also has the advantage of removing the walk of the current lexical context from the common case when this is the only constructor name we need to deal with (implicit or otherwise). I've enhanced the tests to cover this case (and uncovered an unrelated bug which I fixed in r233325). llvm-svn: 233327
* [modules] Restrict the module use-declaration to only appear in top-levelRichard Smith2015-03-263-8/+11
| | | | | | | modules, and allow sub-modules of a module with a use-declaration to make use of the nominated modules. llvm-svn: 233323
* [Modules] Preserve source order for the map of late parsed templates.Chandler Carruth2015-03-261-1/+10
| | | | | | | | | | | | | | | | | | | | Clang was inserting these into a dense map. While it never iterated the dense map during normal compilation, it did when emitting a module. Fix this by using a standard MapVector to preserve the order in which we encounter the late parsed templates. I suspect this still isn't ideal, as we don't seem to remove things from this map even when we mark the templates as no longer late parsed. But I don't know enough about this particular extension to craft a nice, subtle test case covering this. I've managed to get the stress test to at least do some late parsing and demonstrate the core problem here. This patch fixes the test and provides deterministic behavior which is a strict improvement over the prior state. I've cleaned up some of the code here as well to be explicit about inserting when that is what is actually going on. llvm-svn: 233264
* [Modules] Add some more fun code to my modules stress test, this timeChandler Carruth2015-03-262-2/+24
| | | | | | | | templates. Turns out all of this works correctly (so far). But it should cover more code paths and will let me test some things that don't actually work next. llvm-svn: 233263
* [Modules] Make "#pragma weak" undeclared identifiers be trackedChandler Carruth2015-03-263-0/+33
| | | | | | | | | | | | | | | | deterministically. This fixes a latent issue where even Clang's Sema (and diagnostics) were non-deterministic in the face of this pragma. The fix is super simple -- just use a MapVector so we track the order in which these are parsed (or imported). Especially considering how rare they are, this seems like the perfect tradeoff. I've also simplified the client code with judicious use of auto and range based for loops. I've added some pretty hilarious code to my stress test which now survives the binary diff without issue. llvm-svn: 233261
* [Modules] Delete a bunch of complex code for ensuring visible decls inChandler Carruth2015-03-261-1/+1
| | | | | | | | | | | | | | updated decl contexts get emitted. Since this code was added, we have newer vastly simpler code for handling this. The code I'm removing was very expensive and also generated unstable order of declarations which made module outputs non-deterministic. All of the tests continue to pass for me and I'm able to check the difference between the .pcm files after merging modules together. llvm-svn: 233251
* [modules] If we reach a definition of a class for which we already have aRichard Smith2015-03-266-0/+36
| | | | | | | | non-visible definition, skip the new definition and make the old one visible instead of trying to parse it again and failing horribly. C++'s ODR allows us to assume that the two definitions are identical. llvm-svn: 233250
* [Modules] A second attempt at writing out on-disk hash tables for theChandler Carruth2015-03-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | decl context lookup tables. The first attepmt at this caused problems. We had significantly more sources of non-determinism that I realized at first, and my change essentially turned them from non-deterministic output into use-after-free. Except that they weren't necessarily caught by tools because the data wasn't really freed. The new approach is much simpler. The first big simplification is to inline the "visit" code and handle this directly. That works much better, and I'll try to go and clean up the other caller of the visit logic similarly. The second key to the entire approach is that we need to *only* collect names into a stable order at first. We then need to issue all of the actual 'lookup()' calls in the stable order of the names so that we load external results in a stable order. Once we have loaded all the results, the table of results will stop being invalidated and we can walk all of the names again and use the cheap 'noload_lookup()' method to quickly get the results and serialize them. To handle constructors and conversion functions (whose names can't be stably ordered) in this approach, what we do is record only the visible constructor and conversion function names at first. Then, if we have any, we walk the decls of the class and add those names in the order they occur in the AST. The rest falls out naturally. This actually ends up simpler than the previous approach and seems much more robust. It uncovered a latent issue where we were building on-disk hash tables for lookup results when the context was a linkage spec! This happened to dodge all of the assert by some miracle. Instead, add a proper predicate to the DeclContext class and use that which tests both for function contexts and linkage specs. It also uncovered PR23030 where we are forming somewhat bizarre negative lookup results. I've just worked around this with a FIXME in place because fixing this particular Clang bug seems quite hard. I've flipped the first part of the test case I added for stability back on in this commit. I'm taking it gradually to try and make sure the build bots are happy this time. llvm-svn: 233249
* Temporarily disable one more non-determinism flag.Daniel Jasper2015-03-251-1/+1
| | | | | | This turned the bots to red after r233172 which reverted r233156. llvm-svn: 233173
* [Modules] Disable the diff of the merged module, there is still someChandler Carruth2015-03-251-1/+1
| | | | | | non-determinism here, I just got lucky a bunch of times on my system. llvm-svn: 233163
* [Modules] Make the DeclUpdates map be processed in insertion order.Chandler Carruth2015-03-258-0/+179
| | | | | | | | | This fixes my stress tests non-determinism so far. However, I've not started playing with templates, friends, or terrible macros. I've found at least two more seeming instabilities and am just waiting for a test case to actually trigger them. llvm-svn: 233162
* [Modules] Stop creating timestamps for the modules cache and trying toChandler Carruth2015-03-241-6/+6
| | | | | | | | | | | | | prune it when we have disabled implicit module generation and thus are not using any cached modules. Also update a test of explicitly generated modules to pass this CC1 flag correctly. This fixes an issue where Clang was dropping files into the source tree while running its tests. llvm-svn: 233117
* [Modules] Start making explicit modules produce deterministic output.Chandler Carruth2015-03-242-0/+16
| | | | | | | | | | | | | | | | | | | | | There are two aspects of non-determinism fixed here, which was the minimum required to cause at least an empty module to be deterministic. First, the random number signature is only inserted into the module when we are building modules implicitly. The use case for these random signatures is to work around the very fact that modules are not deterministic in their output when working with the implicitly built and populated module cache. Eventually this should go away entirely when we're confident that Clang is producing deterministic output. Second, the on-disk hash table is populated based on the order of iteration over a DenseMap. Instead, use a MapVector so that we can walk it in insertion order. I've added a test that an empty module, when built twice, produces the same binary PCM file. llvm-svn: 233115
* [modules] Remove redundant import of lexical decls when building a lookup tableRichard Smith2015-03-239-14/+30
| | | | | | | | | | | | | | | for a DeclContext, and fix propagation of exception specifications along redeclaration chains. This reverts r232905, r232907, and r232907, which reverted r232793, r232853, and r232853. One additional change is present here to resolve issues with LLDB: distinguish between whether lexical decls missing from the lookup table are local or are provided by the external AST source, and still look in the external source if that's where they came from. llvm-svn: 232928
* Remove empty files left behind by r232907.Benjamin Kramer2015-03-225-0/+0
| | | | llvm-svn: 232909
* Reverting 232853 and 232870 because they depend on 232793,Vince Harron2015-03-226-19/+3
| | | | | | which was reverted because it was causing LLDB test failures llvm-svn: 232907
* Reverting r232793 until some new LLDB failures are discussedVince Harron2015-03-223-11/+11
| | | | llvm-svn: 232905
* [modules] When either redecl chain merging or an update record causes us toRichard Smith2015-03-215-0/+17
| | | | | | | | | give an exception specification to a declaration that didn't have an exception specification in any of our imported modules, emit an update record ourselves. Without this, code importing the current module would not see an exception specification that we could see and might have relied on. llvm-svn: 232870
* [modules] Remove temporary IdentifierInfo lookup results when we're done ↵Richard Smith2015-03-201-3/+2
| | | | | | with them. llvm-svn: 232853
* [modules] Remove some redundant work when building a lookup table for a ↵Richard Smith2015-03-203-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | DeclContext. When we need to build the lookup table for a DeclContext, we used to pull in all lexical declarations for the context; instead, just build a lookup table for the local lexical declarations. We previously didn't guarantee that the imported declarations would be in the returned map, but in some cases we'd happen to put them all in there regardless. Now we're even lazier about this. This unnecessary work was papering over some other bugs: - LookupVisibleDecls would use the DC for name lookups in the TU in C, and this was not guaranteed to find all imported names (generally, the DC for the TU in C is not a reliable place to perform lookups). We now use an identifier-based lookup mechanism for this. - We didn't actually load in the list of eagerly-deserialized declarations when importing a module (so external definitions in a module wouldn't be emitted by users of those modules unless they happened to be deserialized by the user of the module). llvm-svn: 232793
* Make module files passed to a module build via -fmodule-file= available toRichard Smith2015-03-183-0/+14
| | | | | | | | | consumers of that module. Previously, such a file would only be available if the module happened to actually import something from that module. llvm-svn: 232583
* [modules] Fix bug where an anonymous namespace could cause the containingRichard Smith2015-03-176-0/+15
| | | | | | | | | | | | | | | | namespace to not merge properly. We have an invariant here: after a declaration reads its canonical declaration, it can assume the canonical declaration is fully merged. This invariant can be violated if deserializing some declaration triggers the deserialization of a later declaration, because that later declaration can in turn deserialize a redeclaration of that first declaration before it is fully merged. The anonymous namespace for a namespace gets stored with the first declaration of that namespace, which may be before its parent namespace, so defer loading it until after we've finished merging the surrounding namespace. llvm-svn: 232455
* [modules] If we find more formerly-canonical declarations of an entity whileRichard Smith2015-03-166-0/+20
| | | | | | | | | | | building its redecl chains, make sure we pull in the redeclarations of those canonical declarations. It's pretty difficult to reach a situation where we can find more canonical declarations of an entity while building its redecl chains; I think the provided testcase (4 modules and 7 declarations) cannot be reduced further. llvm-svn: 232411
* [modules] Teach the AST reader to handle the case of importing a moduleChandler Carruth2015-03-143-0/+75
| | | | | | | | | | | | | | | | | | | with a subset of the existing target CPU features or mismatched CPU names. While we can't check that the CPU name used to build the module will end up being able to codegen correctly for the translation unit, we actually check that the imported features are a subset of the existing features. While here, rewrite the code to use std::set_difference and have it diagnose all of the differences found. Test case added which walks the set relationships and ensures we diagnose all the right cases and accept the others. No functional change for implicit modules here, just better diagnostics. llvm-svn: 232248
* Test case updates for explicit type parameter to the gep operatorDavid Blaikie2015-03-131-4/+4
| | | | llvm-svn: 232187
* When building a module, all headers of submodules can be used.Daniel Jasper2015-03-131-0/+9
| | | | | | This extends r232159. llvm-svn: 232168
* Make a module "use" also count as use of all its submodulesDaniel Jasper2015-03-133-1/+13
| | | | llvm-svn: 232159
* [Modules] Teach Clang to survive ambiguous macros which come from systemChandler Carruth2015-03-1312-0/+242
| | | | | | | | | | | | | | | | | | | | | headers even if they arrived when merging non-system modules. The idea of this code is that we don't want to warn the user about macros defined multiple times by their system headers with slightly different definitions. We should have this behavior if either the macro comes from a system module, or the definition within the module comes from a system header. Previously, we would warn on ambiguous macros being merged when they came from a users modules even though they only showed up via system headers. By surviving this we can handle common system header macro differences like differing 'const' qualification of pointers due to some headers predating 'const' being valid in C code, even when those systems headers are pre-built into a system module. Differential Revision: http://reviews.llvm.org/D8310 llvm-svn: 232149
OpenPOWER on IntegriCloud