summaryrefslogtreecommitdiffstats
path: root/clang/test/Modules
Commit message (Collapse)AuthorAgeFilesLines
* [modules] Don't diagnose "redefinition" of a friend with a pending definitionRichard Smith2018-03-011-0/+39
| | | | | | if the other definition is a merged copy of the same function. llvm-svn: 326496
* Make module use diagnostics refer to the top-level moduleDaniel Jasper2018-02-241-1/+1
| | | | | | | | | | All use declarations need to be directly placed in the top-level module anyway, knowing the submodule doesn't really help. The header that has the offending #include can easily be seen in the diagnostics source location. Review: https://reviews.llvm.org/D43673 llvm-svn: 326023
* Bring r325915 back.Rafael Espindola2018-02-231-4/+4
| | | | | | | | | | | | | | | The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
* [ODRHash] Fix hashing for friend functions.Richard Trieu2018-02-224-4/+114
| | | | | | | When hashing a templated function, use the hash of the function it was instantiated from. llvm-svn: 325742
* [Modules] Extend -fmodule-name semantic for frameworks with private modulesBruno Cardoso Lopes2018-02-161-0/+12
| | | | | | | | | | | | | Assume Foo.framework with two module maps and two modules Foo and Foo_Private. Framework authors need to skip building both Foo and Foo_Private when using -fmodule-name=Foo, since both are part of the framework and used interchangeably during compilation. rdar://problem/37500098 llvm-svn: 325305
* [Modules] Add more language features to be used with requires-declarationBruno Cardoso Lopes2018-02-142-1/+34
| | | | | | | | | Features added: c99, c11, c17, cplusplus14 and cplusplus17. rdar://problem/36328787 rdar://problem/36668431 llvm-svn: 325154
* Update StmtProfile.cpp to handle zero template arguments.Richard Trieu2018-02-131-0/+15
| | | | | | | Treat having no templates arguments differently than having zero template arguments when profiling. llvm-svn: 325040
* [Modules] Fix remapping from Foo.Private to Foo_Private to happen before ↵Bruno Cardoso Lopes2018-02-121-0/+3
| | | | | | | | | | typo correction Typo correction is the last step here, remapping should come first. rdar://problem/37351970 llvm-svn: 324965
* Re-commit r324490: [DebugInfo] Improvements to representation of enumeration ↵Momchil Velikov2018-02-121-1/+1
| | | | | | | | types (PR36168) Differential revision: https://reviews.llvm.org/D42736 llvm-svn: 324900
* [modules] Fix incorrect diagnostic mapping computation when a module changesRichard Smith2018-02-092-11/+26
| | | | | | | | | | | | | | | diagnostic settings using _Pragma within a macro. The AST writer had previously been assuming that all diagnostic state transitions would occur within a FileID corresponding to a file. When a diagnostic state change occured within a macro, it was unable to form a location for that state change and would instead corrupt the diagnostic state of the "root" node (and thus that of the main compilation). Also introduce a "#pragma clang __debug diag_mapping" debugging utility that I added to track this issue down. llvm-svn: 324695
* Revert [DebugInfo] Improvements to representation of enumeration types ↵Momchil Velikov2018-02-071-1/+1
| | | | | | | | (PR36168)" Revert due to breaking buildbots (LLDB tests) llvm-svn: 324508
* [DebugInfo] Improvements to representation of enumeration types (PR36168)Momchil Velikov2018-02-071-1/+1
| | | | | | | | | | | | | | | This patch: * fixes an incorrect sign-extension of unsigned values, when emitting debug info metadata for enumerators * the enumerators metadata is created with a flag, which determines interpretation of the value bits (signed or unsigned) * the enumerations metadata contains the underlying integer type and a flag, indicating whether this is a C++ "fixed enum" Differential Revision: https://reviews.llvm.org/D42736 llvm-svn: 324490
* Allow BlockDecl in CXXRecord scope to have no access specifier.Richard Trieu2018-01-191-0/+119
| | | | | | | | | Using a BlockDecl in a default member initializer causes it to be attached to CXXMethodDecl without its access specifier being set. This prevents a crash where getAccess is called on this BlockDecl, since that method expects any Decl in CXXRecord scope to have an access specifier. llvm-svn: 322984
* Change memcpy/memove/memset to have dest and source alignment attributes ↵Daniel Neilson2018-01-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | (Step 1). Summary: Upstream LLVM is changing the the prototypes of the @llvm.memcpy/memmove/memset intrinsics. This change updates the Clang tests for this change. The @llvm.memcpy/memmove/memset intrinsics currently have an explicit argument which is required to be a constant integer. It represents the alignment of the dest (and source), and so must be the minimum of the actual alignment of the two. This change removes the alignment argument in favour of placing the alignment attribute on the source and destination pointers of the memory intrinsic call. For example, code which used to read: call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 100, i32 4, i1 false) will now read call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 4 %dest, i8* align 4 %src, i32 100, i1 false) At this time the source and destination alignments must be the same (Step 1). Step 2 of the change, to be landed shortly, will relax that contraint and allow the source and destination to have different alignments. llvm-svn: 322964
* Add context to why test was disabled on WindowsRichard Trieu2018-01-161-0/+1
| | | | | | | test/Modules/odr_hash-Friend.cpp triggers an assertion in MicrosoftMangle.cpp This has been reported in PR35939 llvm-svn: 322593
* Try to suppress Windows testing again.Richard Trieu2018-01-121-1/+1
| | | | llvm-svn: 322420
* Disable test for Windows to fix Windows buildbots.Richard Trieu2018-01-121-0/+2
| | | | llvm-svn: 322405
* [ODRHash] Don't hash friend functions.Richard Trieu2018-01-126-0/+66
| | | | | | | | In certain combinations of templated classes and friend functions, the body of friend functions does not get propagated along with function signature. Exclude friend functions for hashing to avoid this case. llvm-svn: 322350
* Avoid assumption that lit tests are writable (in a couple more places). NFCSam McCall2018-01-091-3/+3
| | | | llvm-svn: 322065
* Test case for r321396Richard Trieu2018-01-0611-0/+77
| | | | | | | | Any hashing for methods should be able to compile this test case without emitting an error. Since the class and method come from the same header from each module, there should be no messages about ODR violations. llvm-svn: 321924
* Serialize the IDNS for a UsingShadowDecl rather than recomputing it.Richard Smith2018-01-061-0/+39
| | | | | | | | | Attempting to recompute it are doomed to fail because the IDNS of a declaration is not necessarily preserved across serialization and deserialization (in turn because whether a friend declaration is visible depends on whether some prior non-friend declaration exists). llvm-svn: 321921
* When name lookup finds a non-imported declaration and looks back along theRichard Smith2018-01-061-0/+37
| | | | | | | | | | redecl chain for an imported declaration, make sure to check the IDNS of prior imported decls. Otherwise we can end up finding an invisible friend declaration and incorrectly believing that it should be visible. llvm-svn: 321916
* Reapply r321781: [Modules] Allow modules specified by -fmodule-map-file to ↵Bruno Cardoso Lopes2018-01-0515-0/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | shadow implicitly found ones When modules come from module map files explicitly specified by -fmodule-map-file= arguments, allow those to override/shadow modules with the same name that are found implicitly by header search. If such a module is looked up by name (e.g. @import), we will always find the one from -fmodule-map-file. If we try to use a shadowed module by including one of its headers report an error. This enables developers to force use of a specific copy of their module to be used if there are multiple copies that would otherwise be visible, for example if they develop modules that are installed in the default search paths. Patch originally by Ben Langmuir, http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151116/143425.html Based on cfe-dev discussion: http://lists.llvm.org/pipermail/cfe-dev/2015-November/046164.html Differential Revision: https://reviews.llvm.org/D31269 rdar://problem/23612102 llvm-svn: 321855
* Revert "[Modules] Allow modules specified by -fmodule-map-file to shadow ↵Bruno Cardoso Lopes2018-01-0415-75/+0
| | | | | | | | | | | implicitly found ones" This reverts r321781 until I fix the leaks pointed out by bots: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/12146 http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/3741 llvm-svn: 321786
* [Modules] Allow modules specified by -fmodule-map-file to shadow implicitly ↵Bruno Cardoso Lopes2018-01-0415-0/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | found ones When modules come from module map files explicitly specified by -fmodule-map-file= arguments, allow those to override/shadow modules with the same name that are found implicitly by header search. If such a module is looked up by name (e.g. @import), we will always find the one from -fmodule-map-file. If we try to use a shadowed module by including one of its headers report an error. This enables developers to force use of a specific copy of their module to be used if there are multiple copies that would otherwise be visible, for example if they develop modules that are installed in the default search paths. Patch originally by Ben Langmuir, http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151116/143425.html Based on cfe-dev discussion: http://lists.llvm.org/pipermail/cfe-dev/2015-November/046164.html Differential Revision: https://reviews.llvm.org/D31269 rdar://problem/23612102 llvm-svn: 321781
* Replace cp -a in various Clang testsHubert Tong2018-01-044-4/+4
| | | | | | | | | | | | | | | | | | | Summary: cp -a is neither part of POSIX nor the LSB. The nearest equivalent under POSIX is cp -RPp; however, cp -R is sufficient for the intended purpose. test/Modules/crash-vfs-headermaps.m is not updated since it requires system-darwin anyway. Reviewers: bruno Reviewed By: bruno Subscribers: bruno, rcraik, cfe-commits Differential Revision: https://reviews.llvm.org/D41545 llvm-svn: 321778
* -gmodules: Emit debug info for implicit module imports via #include.Adrian Prantl2018-01-033-3/+19
| | | | | | | | | | | | When a type is only used as a template parameter and that type is the only type imported from another #include'd module, no skeleton CU for that module is generated, so a consumer doesn't know where to find the type definition. By emitting an import declaration, we can force a skeleton CU to be generated for each imported module. rdar://problem/36266156 llvm-svn: 321754
* [ODRHash] Support ODR violation detection in functions.Richard Trieu2017-12-231-12/+148
| | | | | | | Extend the hashing to functions, which allows detection of function definition mismatches across modules. This is a re-commit of r320230. llvm-svn: 321395
* [Modules] Map missing private submodules from Foo.Private to Foo_PrivateBruno Cardoso Lopes2017-12-221-0/+12
| | | | | | | | | | | | | | In case `@import Foo.Private` fails because the submodule doesn't exist, look for `Foo_Private` (if available) and build/load that module instead. In that process emit a warning and tell the user about the assumption. The intention here is to assist all existing private modules owners (in ObjC and Swift) to migrate to the new `Foo_Private` syntax. rdar://problem/36023940 llvm-svn: 321342
* [Modules] Change private modules rules and warningsBruno Cardoso Lopes2017-12-2225-29/+122
| | | | | | | | | | | | | | | | We used to advertise private modules to be declared as submodules (Foo.Private). This has proven to not scale well since private headers might carry several dependencies, introducing unwanted content into the main module and often causing dep cycles. Change the canonical way to name it to Foo_Private, forcing private modules as top level ones, and provide warnings under -Wprivate-module to suggest fixes for other private naming. Update documentation to reflect that. rdar://problem/31173501 llvm-svn: 321337
* [AST] Incorrectly qualified unscoped enumeration as template actual parameter.Paul Robinson2017-12-211-1/+1
| | | | | | | | | | | | | | | An unscoped enumeration used as template argument, should not have any qualified information about its enclosing scope, as its visibility is global. In the case of scoped enumerations, they must include information about their enclosing scope. Patch by Carlos Alberto Enciso! Differential Revision: https://reviews.llvm.org/D39239 llvm-svn: 321312
* Revert r320230 to fix buildbots.Richard Trieu2017-12-091-148/+12
| | | | llvm-svn: 320239
* [ODRHash] Support ODR violation detection in functions.Richard Trieu2017-12-091-12/+148
| | | | | | | Extend the hashing to functions, which allows detection of function definition mismatches across modules. llvm-svn: 320230
* Use an even more precise triple to avoid errors on Darwin, where we don't ↵Richard Smith2017-12-051-1/+1
| | | | | | use comdats for inline entities. llvm-svn: 319835
* Give this test a triple to avoid failures on MS bots.Richard Smith2017-12-051-1/+1
| | | | llvm-svn: 319817
* Generalize "static data member instantiated" notification to cover variable ↵Richard Smith2017-12-051-0/+24
| | | | | | | | | templates too. While here, split the "point of instantiation changed" notification out from it; these two really are orthogonal changes. llvm-svn: 319727
* Change path used in a test from r318503 to work on windowsBruno Cardoso Lopes2017-11-171-1/+1
| | | | | | http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/13565 llvm-svn: 318507
* [PCH+Modules] Improve diagnosticts to help out users pass an extra header ↵Bruno Cardoso Lopes2017-11-171-0/+17
| | | | | | | | | | | | | | | search path When mixing PCH and Implicit Modules, missing a header search path can lead to the implicit built PCM to complaint about not finding its matching module map. Instead of adding more magic to implicit modules engine, add a note to help the user add the appropriate path. rdar://problem/33388847 llvm-svn: 318503
* Update ODR hashing testsRichard Trieu2017-11-041-120/+723
| | | | | | | | Add a mix of postive and negative tests to check that wrong Decls won't be flagged in the diagnostic. Split the check everything test and moved the pieces closer to where the related tests are. llvm-svn: 317394
* Modular Codegen: Don't home always_inline functionsDavid Blaikie2017-11-023-1/+9
| | | | | | | | Since they'll likely (not always - if the address is taken, etc) be inlined away, even at -O0, separately provided weak definitions are likely to be unused so skip all of that. llvm-svn: 317279
* Modular Codegen: Don't home/modularize static functions in headersDavid Blaikie2017-11-021-3/+9
| | | | | | | | | | | | | | | | Consistent with various workarounds in the backwards compatible modules that allow static functions in headers to exist, be deduplicated to some degree, and not generally fail right out of the gate... do the same with modular codegen as there are enough cases (including in libstdc++ and in LLVM itself - though I cleaned up the easy ones) that it's worth supporting as a migration/backcompat step. Simply create a separate, internal linkage function in each object that needs it. If an available_externally/modularized function references a static function, but the modularized function is eventually dropped and not inlined, the static function will be dropped as unreferenced. llvm-svn: 317274
* PR33746: Store the 'inline'ness of a static data member with the update recordRichard Smith2017-11-021-0/+30
| | | | | | | | | for instantiating its definition. We model the 'inline'ness as being instantiated with the static data member in order to track whether the declaration has become a definition yet. llvm-svn: 317147
* [modules] Retain multiple using-directives in the same scope even if they ↵Richard Smith2017-10-301-0/+37
| | | | | | | | | | | | name the same namespace. They might have different visibility, and thus discarding all but one of them can result in rejecting valid code. Also fix name lookup to cope with multiple using-directives being found that denote the same namespace, where some are not visible -- don't cache an "already visited" state for a using-directive that we didn't visit because it was hidden. llvm-svn: 316965
* [modules] Add a regression test for merging anon decls in extern C contexts.Vassil Vassilev2017-10-241-0/+19
| | | | llvm-svn: 316444
* [modules] When finding the owning module of an instantiated context in templateRichard Smith2017-10-181-0/+51
| | | | | | | instantiation, follow lexical parents not semantic ones: we want to find the module where the pattern was written. llvm-svn: 316055
* Revert r314955: "Remove PendingBody mechanism for function and ObjC method ↵Daniel Jasper2017-10-111-43/+0
| | | | | | | | | | | deserialization." This is breaking a build of https://github.com/abseil/abseil-cpp and so likely not really NFC. Also reverted subsequent r314956/7. I'll forward reproduction instructions to Richard. llvm-svn: 315439
* [modules] Fix visibility checking for using declarations via ADL.Richard Smith2017-10-111-0/+40
| | | | | | | We want to check whether the using (shadow) declaration itself is visible, not whether its target is visible. llvm-svn: 315408
* [modules] Only take visible using-directives into account during name lookup.Richard Smith2017-10-111-0/+62
| | | | llvm-svn: 315402
* [Modules TS] Module ownership semantics for redeclarations.Richard Smith2017-10-101-0/+12
| | | | | | | | | | | | | | | | | When declaring an entity in the "purview" of a module, it's never a redeclaration of an entity in the purview of a default module or in no module ("in the global module"). Don't consider those other declarations as possible redeclaration targets if they're not visible, and reject any cases where we pick a prior visible declaration that violates this rule. This reinstates r315251 and r315256, reverted in r315309 and r315308 respectively, tweaked to avoid triggering a linkage calculation when declaring implicit special members (this exposed our pre-existing issue with typedef names for linkage changing the linkage of types whose linkage has already been computed and cached in more cases). A testcase for that regression has been added in r315366. llvm-svn: 315379
* Revert "[Modules TS] Avoid computing the linkage of the enclosing ↵Eric Liu2017-10-101-12/+0
| | | | | | | | DeclContext for a declaration in the global module." This reverts commit r315256. See the original commit thread for reason. llvm-svn: 315308
OpenPOWER on IntegriCloud