summaryrefslogtreecommitdiffstats
path: root/clang/test/Modules
Commit message (Collapse)AuthorAgeFilesLines
...
* [ODRHash] Hash typedefs and usings statements in classes.Richard Trieu2017-03-081-0/+105
| | | | llvm-svn: 297246
* [modules] Add missing test from r297030.Vassil Vassilev2017-03-063-0/+17
| | | | llvm-svn: 297037
* [ODRHash] Try again to fix build bot.Richard Trieu2017-03-041-3/+3
| | | | llvm-svn: 296958
* [ODRHash] Change test to try to appease buildbot.Richard Trieu2017-03-041-0/+2
| | | | llvm-svn: 296953
* [ODRHash] Add support for detecting different method properties.Richard Trieu2017-03-041-2/+119
| | | | | | | | Now print diagnostics for static, virtual, inline, volatile, and const differences in methods. Also use DeclarationName instead of IdentifierInfo for additional robustness in diagnostic printing. llvm-svn: 296932
* [Test] NFC: Fixed typo in commentsCharles Li2017-03-012-5/+5
| | | | | | Changed "declerations" to "declarations" llvm-svn: 296648
* [ODRHash] Add basic support for CXXRecordDeclRichard Trieu2017-02-281-0/+41
| | | | llvm-svn: 296521
* [modules] For -module-file-info, print out the resource dir path, since it ↵Argyrios Kyrtzidis2017-02-251-0/+1
| | | | | | is included in the module hash. llvm-svn: 296261
* [ODRHash] Finish FieldDecl support by handling mutable and initializers.Richard Trieu2017-02-241-0/+50
| | | | | | https://reviews.llvm.org/rL296170 llvm-svn: 296198
* [Test] Make Lit tests C++11 compatible #10Charles Li2017-02-242-0/+19
| | | | | | Differential Revision: https://reviews.llvm.org/D21626 llvm-svn: 296193
* [ODRHash] Add handling of bitfieldsRichard Trieu2017-02-241-0/+53
| | | | | | Differential Revision: https://reviews.llvm.org/D21675 llvm-svn: 296170
* [ODRHash] Add handling of TypedefType and DeclarationNameRichard Trieu2017-02-241-0/+42
| | | | | | Differential Revision: https://reviews.llvm.org/D21675 llvm-svn: 296078
* Represent pass_object_size attrs in ExtParameterInfoGeorge Burgess IV2017-02-242-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ODRHash] Handle types in ODR hashing.Richard Trieu2017-02-231-0/+14
| | | | | | | | | | Fields will now have their types added to the hash, allowing for detection of mismatched field types. This detection allows the existing ODR checking to produce the correct message. Differential Revision: https://reviews.llvm.org/D21675 llvm-svn: 295931
* [ODRHash] Add IdentiferInfo and FieldDecl support.Richard Trieu2017-02-231-0/+47
| | | | | | | | | IdentifierInfo is hashed based on the stored string. FieldDecl versus other Decl is now detected, as well as differently named fields. Differential Revision: https://reviews.llvm.org/D21675 llvm-svn: 295911
* [ObjC][Modules] Don't perform property lookup in hidden class extensionsAlex Lorenz2017-02-222-0/+11
| | | | | | rdar://30603803 llvm-svn: 295903
* [ODRHash] static_cast and Stmt hashing.Richard Trieu2017-02-221-1/+71
| | | | | | | | | | Add support for static_cast in classes. Add pointer-independent profiling for Stmt's, sharing most of the logic with Stmt::Profile. This is the first of the deep sub-Decl diffing for error messages. Differential Revision: https://reviews.llvm.org/D21675 llvm-svn: 295890
* Add more ODR checking.Richard Trieu2017-02-221-0/+412
| | | | | | | | | | Add the basics for the ODRHash class, which will only process Decl's from a whitelist, which currently only has AccessSpecDecl. Different access specifiers in merged classes can now be detected. Differential Revision: https://reviews.llvm.org/D21675 llvm-svn: 295800
* Revert r295421, new ODR checker for modules, to fix build bot.Richard Trieu2017-02-172-1161/+0
| | | | llvm-svn: 295427
* Add better ODR checking for modules.Richard Trieu2017-02-172-0/+1161
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A slightly weaker form of ODR checking than previous attempts, but hopefully won't break the modules build bot. Future work will be needed to catch all cases. When objects are imported for modules, there is a chance that a name collision will cause an ODR violation. Previously, only a small number of such violations were detected. This patch provides a stronger check based on AST nodes. The information needed to uniquely identify an object is taken from the AST and put into a one-dimensional byte stream. This stream is then hashed to give a value to represent the object, which is stored with the other object data in the module. When modules are loaded, and Decl's are merged, the hash values of the two Decl's are compared. Only Decl's with matched hash values will be merged. Mismatch hashes will generate a module error, and if possible, point to the first difference between the two objects. The transform from AST to byte stream is a modified depth first algorithm. Due to references between some AST nodes, a pure depth first algorithm could generate loops. For Stmt nodes, a straight depth first processing occurs. For Type and Decl nodes, they are replaced with an index number and only on first visit will these nodes be processed. As an optimization, boolean values are saved and stored together in reverse order at the end of the byte stream to lower the ammount of data that needs to be hashed. Compile time impact was measured at 1.5-2.0% during module building, and negligible during builds without module building. Differential Revision: https://reviews.llvm.org/D21675 llvm-svn: 295421
* Revert r295284: Add better ODR checking for modules.Richard Trieu2017-02-162-1160/+0
| | | | | | Fix modules build bot. llvm-svn: 295293
* Add better ODR checking for modules.Richard Trieu2017-02-162-0/+1160
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit r293585 that was reverted in r293611 with new fixes. The previous issue was determined to be an overly aggressive AST visitor from forward declared objects. The visitor will now only deeply visit certain Decl's and only do a shallow information extraction from all other Decl's. When objects are imported for modules, there is a chance that a name collision will cause an ODR violation. Previously, only a small number of such violations were detected. This patch provides a stronger check based on AST nodes. The information needed to uniquely identify an object is taken from the AST and put into a one-dimensional byte stream. This stream is then hashed to give a value to represent the object, which is stored with the other object data in the module. When modules are loaded, and Decl's are merged, the hash values of the two Decl's are compared. Only Decl's with matched hash values will be merged. Mismatch hashes will generate a module error, and if possible, point to the first difference between the two objects. The transform from AST to byte stream is a modified depth first algorithm. Due to references between some AST nodes, a pure depth first algorithm could generate loops. For Stmt nodes, a straight depth first processing occurs. For Type and Decl nodes, they are replaced with an index number and only on first visit will these nodes be processed. As an optimization, boolean values are saved and stored together in reverse order at the end of the byte stream to lower the ammount of data that needs to be hashed. Compile time impact was measured at 1.5-2.0% during module building, and negligible during builds without module building. Differential Revision: https://reviews.llvm.org/D21675 llvm-svn: 295284
* [Modules] Consider enable_if attrs in isSameEntity.George Burgess IV2017-02-153-0/+38
| | | | | | | | | | | | | | 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-088-68/+83
| | | | llvm-svn: 294512
* [PCH] Fix a regression when PCH is used with -fmodulesBruno Cardoso Lopes2017-02-079-0/+32
| | | | | | | | | | | | | | | | | 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
* Revert r293585 "Add better ODR checking for modules."Sam McCall2017-01-312-1081/+0
| | | | | | | | | | | We're seeing what we believe are false positives. (It's hard to tell with the available diagnostics, and I'm not sure how to reduce them yet). I'll send Richard reproduction details offline. djasper/chandlerc suggested this should be a warning for now, to make rolling it out feasible. llvm-svn: 293611
* Add better ODR checking for modules.Richard Trieu2017-01-312-0/+1081
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When objects are imported for modules, there is a chance that a name collision will cause an ODR violation. Previously, only a small number of such violations were detected. This patch provides a stronger check based on AST nodes. The information needed to uniquely identify an object is taked from the AST and put into a one-dimensional byte stream. This stream is then hashed to give a value to represent the object, which is stored with the other object data in the module. When modules are loaded, and Decl's are merged, the hash values of the two Decl's are compared. Only Decl's with matched hash values will be merged. Mismatch hashes will generate a module error, and if possible, point to the first difference between the two objects. The transform from AST to byte stream is a modified depth first algorithm. Due to references between some AST nodes, a pure depth first algorithm could generate loops. For Stmt nodes, a straight depth first processing occurs. For Type and Decl nodes, they are replaced with an index number and only on first visit will these nodes be processed. As an optimization, boolean values are saved and stored together in reverse order at the end of the byte stream to lower the ammount of data that needs to be hashed. Compile time impact was measured at 1.5-2.0% during module building, and negligible during builds without module building. Differential Revision: https://reviews.llvm.org/D21675 llvm-svn: 293585
* Tidy up codegen modules test & make it x86 specific since it relies on ↵David Blaikie2017-01-301-8/+9
| | | | | | Itanium name manglings llvm-svn: 293457
* Prototype of modules codegenDavid Blaikie2017-01-306-0/+80
| | | | | | | | | | | | | | | | | | | | | 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-2614-0/+70
| | | | 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-263-0/+6
| | | | | | | | | | | | | | 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-262-0/+57
| | | | | | | | | | | | | | | | | | | | | | | 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
* Revert r292508 given that we intend to remove driver options for cxx modules.Manman Ren2017-01-201-5/+0
| | | | llvm-svn: 292639
* Module: Improve diagnostic message when cxx modules are disabled and @import ↵Manman Ren2017-01-191-0/+5
| | | | | | | | is used in Objective CXX. rdar://problem/19399671 llvm-svn: 292508
* [Modules] Correct test comment from obsolete earlier version of code. NFCGraydon Hoare2017-01-181-1/+1
| | | | | | | | | | | | | | | | Summary: Code committed in rL290219 went through a few iterations; test wound up with stale comment. Reviewers: doug.gregor, manmanren Reviewed By: manmanren Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D28790 llvm-svn: 292435
* [Modules] Fix misleading warning about missing textual header in umbrella headerBruno Cardoso Lopes2017-01-126-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | 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-125-0/+40
| | | | | | | | | | | | | | | | | 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-113-0/+12
| | | | | | | | | | | 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-113-12/+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-1120-1/+131
| | | | | | | | | | | | 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-113-0/+12
| | | | | | | | | are building an implemenation of module X. This fixes a regression caused by r280409. rdar://problem/29930553 llvm-svn: 291628
* Check that template template arguments match template template parametersRichard Smith2017-01-091-8/+2
| | | | | | | | | | | | | | | properly even when a non-type template parameter has a dependent type. Previously, if a non-type template parameter was dependent, but not dependent on an outer level of template parameter, we would not match the type of the parameter. Under [temp.arg.template], we are supposed to check that the types are equivalent, which means checking for syntactic equivalence in the dependent case. This also fixes some accepts-invalids when passing templates with auto-typed non-type template parameters as template template arguments. llvm-svn: 291512
* PCH: fix a regression that reports a module is defined in both pch and pcm.Manman Ren2017-01-097-0/+19
| | | | | | | | | | | | | | | | | 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
* When producing a name of a partial specialization in a diagnostic, use theRichard Smith2016-12-241-8/+8
| | | | | | | template arguments as written rather than the canonical template arguments, so we print more user-friendly names for template parameters. llvm-svn: 290483
* Make '-disable-llvm-optzns' an alias for '-disable-llvm-passes'.Chandler Carruth2016-12-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Much to my surprise, '-disable-llvm-optzns' which I thought was the magical flag I wanted to get at the raw LLVM IR coming out of Clang deosn't do that. It still runs some passes over the IR. I don't want that, I really want the *raw* IR coming out of Clang and I strongly suspect everyone else using it is in the same camp. There is actually a flag that does what I want that I didn't know about called '-disable-llvm-passes'. I suspect many others don't know about it either. It both does what I want and is much simpler. This removes the confusing version and makes that spelling of the flag an alias for '-disable-llvm-passes'. I've also moved everything in Clang to use the 'passes' spelling as it seems both more accurate (*all* LLVM passes are disabled, not just optimizations) and much easier to remember and spell correctly. This is part of simplifying how Clang drives LLVM to make it cleaner to wire up to the new pass manager. Differential Revision: https://reviews.llvm.org/D28047 llvm-svn: 290392
* [CrashReproducer] Add support for merging -ivfsoverlayBruno Cardoso Lopes2016-12-221-0/+45
| | | | | | | | | | | Merge all VFS mapped files inside -ivfsoverlay inputs into the vfs overlay provided by the crash reproducer. This is the last missing piece to allow crash reproducers to fully work with user frameworks; when combined with headermaps, it allows clang to find additional frameworks. rdar://problem/27913709 llvm-svn: 290326
* Fix windows build breakage in r290219. Unix path separators in testcase.Graydon Hoare2016-12-211-1/+1
| | | | llvm-svn: 290233
* [modules] Handle modules with nonstandard names in module.private.modulemapsGraydon Hoare2016-12-215-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CrashReproducer] Collect PCH included via -include-pchBruno Cardoso Lopes2016-12-121-0/+43
| | | | | | | | | | | | Collect the necessary input PCH files. Do not try to validate the AST before copying it out because if the crash is in this path, we won't be able to collect it. Instead only check if it's a file containg an AST. rdar://problem/27913709 llvm-svn: 289460
OpenPOWER on IntegriCloud