summaryrefslogtreecommitdiffstats
path: root/clang/test/Modules
Commit message (Collapse)AuthorAgeFilesLines
* Fix an assert in -Wquoted-include-in-framework-headerErik Pilkington2018-09-203-0/+5
| | | | | | | | Fixes rdar://43692300 Differential revision: https://reviews.llvm.org/D52253 llvm-svn: 342679
* [Modules] Add platform and environment features to requires clauseBruno Cardoso Lopes2018-09-181-0/+79
| | | | | | | | | | | | | Allows module map writers to add build requirements based on platform/os. This helps when target features and language dialects aren't enough to conditionalize building a module, among other things, it allow module maps for different platforms to live in the same file. rdar://problem/43909745 Differential Revision: https://reviews.llvm.org/D51910 llvm-svn: 342499
* [modules] Support use of -E on modules built from the command line.Richard Smith2018-09-151-0/+5
| | | | llvm-svn: 342306
* [modules] Frontend support for building a header module from a list ofRichard Smith2018-09-153-0/+52
| | | | | | headaer files. llvm-svn: 342304
* [ODRHash] Fix early exit that skipped code.Richard Trieu2018-09-141-0/+1
| | | | | | | | | | There is a bit of code at the end of AddDeclaration that should be run on every exit of the function. However, there was an early exit beforehand that could be triggered, which causes a small amount of data to skip the hashing, leading to false positive mismatch. Use a separate function so that this code is always run. llvm-svn: 342199
* Print correctly dependency paths on WindowsDavid Bolvansky2018-09-131-3/+3
| | | | | | | | | | | | | | | | | | | Summary: Before: main.o: main.c ../include/lib\test.h After: main.o: main.c ../include/lib/test.h Fixes PR38877 Reviewers: zturner Subscribers: xbolva00, cfe-commits Differential Revision: https://reviews.llvm.org/D51847 llvm-svn: 342139
* Track definition merging on the canonical declaration even when localRichard Smith2018-09-121-0/+34
| | | | | | | | | | | | | | submodule visibility is disabled. Attempting to pick a specific declaration to make visible when the module containing the merged declaration becomes visible is error-prone, as we don't yet know which declaration we'll choose to be the definition when we are informed of the merging. This reinstates r342019, reverted in r342020. The regression previously observed after this commit was fixed in r342096. llvm-svn: 342097
* When we leave a module header, make that header visible in itsRichard Smith2018-09-125-0/+32
| | | | | | includer's context, even if its overall module is unavailable. llvm-svn: 342096
* Revert r342019, "Track definition merging on the canonical declarationRichard Smith2018-09-121-34/+0
| | | | | | | | | even when [...]" Further testing has revealed that this causes build breaks during explicit module compilations. llvm-svn: 342020
* Track definition merging on the canonical declaration even when localRichard Smith2018-09-121-0/+34
| | | | | | | | | | | submodule visibility is disabled. Attempting to pick a specific declaration to make visible when the module containing the merged declaration becomes visible is error-prone, as we don't yet know which declaration we'll choose to be the definition when we are informed of the merging. llvm-svn: 342019
* Consistently create a new declaration when merging a pre-existing butRichard Smith2018-09-121-1/+1
| | | | | | | | | | | | | | | | hidden definition with a would-be-parsed redefinition. This permits a bunch of cleanups. In particular, we no longer need to take merged definitions into account when checking declaration visibility, only when checking definition visibility, which makes certain visibility checks take linear instead of quadratic time. We could also now remove the UPD_DECL_EXPORTED update record and track on each declaration whether it was demoted from a definition (as we already do for variables), but I'm not doing that in this patch to keep the changes here simpler. llvm-svn: 342018
* Fix tracking of merged definitions when the merge target is also mergedRichard Smith2018-09-121-0/+34
| | | | | | into something else. llvm-svn: 342017
* [Modules] Add imported modules to the output of -module-file-infoBruno Cardoso Lopes2018-09-111-0/+1
| | | | | | | | | Fix a bug in the deserialization of IMPORTS section and allow for imported modules to also be printed with -module-file-info. rdar://problem/43867753 llvm-svn: 341902
* PR38627: Fix handling of exception specification adjustment forRichard Smith2018-09-052-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | destructors. We previously tried to patch up the exception specification after completing the class, which went wrong when the exception specification was needed within the class body (in particular, by a friend redeclaration of the destructor in a nested class). We now mark the destructor as having a not-yet-computed exception specification immediately after creating it. This requires delaying various checks against the exception specification (where we'd previously have just got the wrong exception specification, and now find we have an exception specification that we can't compute yet) when those checks fire while the class is being defined. This also exposed an issue that we were missing a CodeSynthesisContext for computation of exception specifications (otherwise we'd fail to make the module containing the definition of the class visible when computing its members' exception specs). Adding that incidentally also gives us a diagnostic quality improvement. This has also exposed an pre-existing problem: making the exception specification evaluation context a non-SFINAE context (as it should be) results in a bootstrap failure; PR38850 filed for this. llvm-svn: 341499
* Remove unnecessary options from test RUN lines.Richard Trieu2018-09-052-6/+6
| | | | | | | These tests do not check the color printing, so color options should not be used when running them. llvm-svn: 341498
* Add triple to test case.Richard Trieu2018-09-051-1/+3
| | | | | | | This test uses enums, which have different behavior when targeting different systems. Specifying a triple will give predictable behavior to this test. llvm-svn: 341496
* [ODRHash] Extend hash to support all Type's.Richard Trieu2018-09-046-2/+1129
| | | | llvm-svn: 341421
* Ensure canonical type is actually canonical.Richard Trieu2018-08-301-0/+74
| | | | | | | | | ASTContext::applyObjCProtocolQualifiers will return a canonical type when given a canonical type and an array of canonical protocols. If the protocols are not canonical then the returned type is also not canonical. Since a canonical type is needed, canonicalize the returned type before using it. This later prevents a type from having a non-canonical canonical type. llvm-svn: 341013
* [CMake] Use normalized Windows target triplesPetr Hosek2018-08-096-6/+6
| | | | | | | | | | | Changes the default Windows target triple returned by GetHostTriple.cmake from the old environment names (which we wanted to move away from) to newer, normalized ones. This also requires updating all tests to use the new systems names in constraints. Differential Revision: https://reviews.llvm.org/D47381 llvm-svn: 339307
* Diagnose invalid cv-qualifiers for friend decls.Eli Friedman2018-08-031-18/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D45712 llvm-svn: 338931
* [modules] Defer merging deduced return types.Richard Smith2018-08-032-0/+9
| | | | | | | | | | | We can't read a deduced return type until we are sure that the types referred to by it are not in the middle of being loaded. So defer all reading of such deduced return types until the end of the recursive deserialization step. Also, when we load a function type that has a deduced return type, update all other redeclarations of the function to have that deduced return type. llvm-svn: 338798
* Fix assertion failure when emitting code for a merged lambda.Richard Smith2018-08-021-1/+1
| | | | llvm-svn: 338766
* [Modules] Do not emit relocation error when -fno-validate-pch is setYuka Takahashi2018-08-011-0/+2
| | | | | | | | | | | | Summary: Clang emits error when implicit modules was relocated from the first build directory. However this was biting our usecase where we copy the contents of build directory to another directory in order to distribute. Differential Revision: https://reviews.llvm.org/D49852 llvm-svn: 338503
* [ODRHash] Support hashing enums.Richard Trieu2018-07-251-0/+171
| | | | llvm-svn: 337978
* [PCH+Modules] Load -fmodule-map-file content before including PCHsBruno Cardoso Lopes2018-07-191-0/+16
| | | | | | | | | | | | | | | | Consider: 1) Generate PCH with -fmodules and -fmodule-map-file 2) Use PCH with -fmodules and the same -fmodule-map-file If we don't load -fmodule-map-file content before including PCHs, the modules that are dependencies in PCHs cannot get loaded, since there's no matching module map file when reading back the AST. rdar://problem/40852867 Differential Revision: https://reviews.llvm.org/D48685 llvm-svn: 337447
* Reapply r336660: [Modules] Autoload subdirectory modulemaps with specific ↵Bruno Cardoso Lopes2018-07-186-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | LangOpts Summary: Reproducer and errors: https://bugs.llvm.org/show_bug.cgi?id=37878 lookupModule was falling back to loadSubdirectoryModuleMaps when it couldn't find ModuleName in (proper) search paths. This was causing iteration over all files in the search path subdirectories for example "/usr/include/foobar" in bugzilla case. Users don't expect Clang to load modulemaps in subdirectories implicitly, and also the disk access is not cheap. if (AllowExtraModuleMapSearch) true with ObjC with @import ModuleName. Reviewers: rsmith, aprantl, bruno Subscribers: cfe-commits, teemperor, v.g.vassilev Differential Revision: https://reviews.llvm.org/D48367 llvm-svn: 337430
* [modules] Print input files when -module-file-info file switch is passed.Vassil Vassilev2018-07-181-0/+10
| | | | | | | | | This patch improves traceability of duplicated header files which end up in multiple pcms. Differential Revision: https://reviews.llvm.org/D47118 llvm-svn: 337353
* Revert "[modules] Fix 37878; Autoload subdirectory modulemaps with specific ↵Bruno Cardoso Lopes2018-07-126-33/+0
| | | | | | | | | | | | | | | LangOpts" This reverts commit f40124d4f05ecf4f880cf4e8f26922d861f705f3 / r336660. This change shouldn't be affecting `@import` behavior, but turns out it is: https://ci.swift.org/view/swift-master-next/job/oss-swift-incremental-RA-osx-master-next/2800/consoleFull#-12570166563122a513-f36a-4c87-8ed7-cbc36a1ec144 Working on a reduced testcase for this, reverting in the meantime. rdar://problem/42102222 llvm-svn: 336920
* [modules] Fix 37878; Autoload subdirectory modulemaps with specific LangOptsYuka Takahashi2018-07-106-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Reproducer and errors: https://bugs.llvm.org/show_bug.cgi?id=37878 lookupModule was falling back to loadSubdirectoryModuleMaps when it couldn't find ModuleName in (proper) search paths. This was causing iteration over all files in the search path subdirectories for example "/usr/include/foobar" in bugzilla case. Users don't expect Clang to load modulemaps in subdirectories implicitly, and also the disk access is not cheap. if (AllowExtraModuleMapSearch) true with ObjC with @import ModuleName. Reviewers: rsmith, aprantl, bruno Subscribers: cfe-commits, teemperor, v.g.vassilev Differential Revision: https://reviews.llvm.org/D48367 llvm-svn: 336660
* [ODRHash] Merge the two function hashes into one.Richard Trieu2018-07-101-0/+222
| | | | | | | | | | | Functions that are a sub-Decl of a record were hashed differently than other functions. This change keeps the AddFunctionDecl function and the hash of records now calls this function. In addition, AddFunctionDecl has an option to perform a hash as if the body was absent, which is required for some checks after loading modules. Additional logic prevents multiple error message from being printed. llvm-svn: 336632
* PR33924: merge local declarations that have linkage of some kind withinRichard Smith2018-07-046-0/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | merged function definitions; also merge functions with deduced return types. This seems like two independent fixes, but unfortunately they are hard to separate because it's challenging to reliably test either one of them without also testing the other. A complication arises with deduced return type support: we need the type of the function in order to know how to merge it, but we can't load the actual type of the function because it might reference an entity declared within the function (and we need to have already merged the function to correctly merge that entity, which we would need to do to determine if the function types match). So we instead compare the declared function type when merging functions, and defer loading the actual type of a function with a deduced type until we've finished loading and merging the function. This reverts r336175, reinstating r336021, with one change (for PR38015): we look at the TypeSourceInfo of the first-so-far declaration of each function when considering whether to merge two functions. This works around a problem where the calling convention in the TypeSourceInfo for subsequent redeclarations may not match if it was implicitly adjusted. llvm-svn: 336240
* Revert r336021 "PR33924: merge local declarations that have linkage of some ↵Hans Wennborg2018-07-033-108/+0
| | | | | | | | | | | | | | | | | | | | | | | | | kind within" This caused test failures in 32-bit builds (PR38015). > merged function definitions; also merge functions with deduced return > types. > > This seems like two independent fixes, but unfortunately they are hard > to separate because it's challenging to reliably test either one of them > without also testing the other. > > A complication arises with deduced return type support: we need the type > of the function in order to know how to merge it, but we can't load the > actual type of the function because it might reference an entity > declared within the function (and we need to have already merged the > function to correctly merge that entity, which we would need to do to > determine if the function types match). So we instead compare the > declared function type when merging functions, and defer loading the > actual type of a function with a deduced type until we've finished > loading and merging the function. llvm-svn: 336175
* Add protocol redefinition to the current scope/contextBruno Cardoso Lopes2018-06-305-0/+23
| | | | | | | | | | | | Not doing so causes the AST writter to assert since the decl in question never gets emitted. This is fine when modules is not used, but otherwise we need to serialize something other than garbage. rdar://problem/39844933 Differential Revision: https://reviews.llvm.org/D47297 llvm-svn: 336031
* PR33924: merge local declarations that have linkage of some kind withinRichard Smith2018-06-293-0/+108
| | | | | | | | | | | | | | | | | | | | | merged function definitions; also merge functions with deduced return types. This seems like two independent fixes, but unfortunately they are hard to separate because it's challenging to reliably test either one of them without also testing the other. A complication arises with deduced return type support: we need the type of the function in order to know how to merge it, but we can't load the actual type of the function because it might reference an entity declared within the function (and we need to have already merged the function to correctly merge that entity, which we would need to do to determine if the function types match). So we instead compare the declared function type when merging functions, and defer loading the actual type of a function with a deduced type until we've finished loading and merging the function. llvm-svn: 336021
* Spurious commit just to help Richard, because git is weird.David Blaikie2018-06-291-0/+1
| | | | llvm-svn: 336020
* [ODRHash] Do not rely on Type* when computing the hash.Vassil Vassilev2018-06-286-0/+46
| | | | | | | | | | | | | | | | | ODRHash aims to provide Cross-TU stable hashing. Making clang::Type pointer part of the hash connects (remotely) the ODRHash with the TU-specific ::Profile hasher. r332281 exposed the issue by changing the way the ASTContext different elaborated types if there is an owning tag. In that case, ODRHash stores two different types in its TypeMap which yields false ODR violation in modules. The current state of implementation shouldn't need the TypeMap concept anymore. Rip it out. Differential Revision: https://reviews.llvm.org/D48524 llvm-svn: 335853
* [modules] Do not serialize / deserialize pending new/delete mismatchRichard Smith2018-06-281-0/+23
| | | | | | | | | | checks across module boundaries. This was causing us to load constructor definitions for all consumers of a module with a pending check. (In one case we saw ~7% of total frontend time spent loading constructors for this check.) llvm-svn: 335807
* [modules] Ensure that an in-class function definition is attached to theRichard Smith2018-06-281-0/+34
| | | | | | | | | | | declaration of the function that ends up in the primary definition of the class. ... at least for class templates. This is necessary for us to be able to track when an inline friend function has a definition that needs to be (lazily) instantiated. llvm-svn: 335805
* [Modules][ObjC] Warn on the use of '@import' in framework headersBruno Cardoso Lopes2018-06-274-0/+25
| | | | | | | | | | | Using @import in framework headers inhibit the use of such headers when not using modules, this is specially bad for headers that end up in the SDK (or any other system framework). Add a warning to give users some indication that this is discouraged. rdar://problem/39192894 llvm-svn: 335780
* Fix tests from r335542 to use %hmaptoolBruno Cardoso Lopes2018-06-251-2/+2
| | | | llvm-svn: 335543
* Warning for framework include violation from Headers to PrivateHeadersBruno Cardoso Lopes2018-06-2513-0/+122
| | | | | | | | | | | | | | | | | | | | | | | | | | Framework vendors usually layout their framework headers in the following way: Foo.framework/Headers -> "public" headers Foo.framework/PrivateHeader -> "private" headers Since both headers in both directories can be found with #import <Foo/some-header.h>, it's easy to make mistakes and include headers in Foo.framework/PrivateHeader from headers in Foo.framework/Headers, which usually configures a layering violation on Darwin ecosystems. One of the problem this causes is dep cycles when modules are used, since it's very common for "private" modules to include from the "public" ones; adding an edge the other way around will trigger cycles. Add a warning to catch those cases such that: ./A.framework/Headers/A.h:1:10: warning: public framework header includes private framework header 'A/APriv.h' #include <A/APriv.h> ^ rdar://problem/38712182 llvm-svn: 335542
* Re-apply: Warning for framework headers using double quote includesBruno Cardoso Lopes2018-06-2212-0/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce -Wquoted-include-in-framework-header, which should fire a warning whenever a quote include appears in a framework header and suggest a fix-it. For instance, for header A.h added in the tests, this is how the warning looks like: ./A.framework/Headers/A.h:2:10: warning: double-quoted include "A0.h" in framework header, expected angle-bracketed instead [-Wquoted-include-in-framework-header] #include "A0.h" ^~~~~~ <A/A0.h> ./A.framework/Headers/A.h:3:10: warning: double-quoted include "B.h" in framework header, expected angle-bracketed instead [-Wquoted-include-in-framework-header] #include "B.h" ^~~~~ <B.h> This helps users to prevent frameworks from using local headers when in fact they should be targetting system level ones. The warning is off by default. Differential Revision: https://reviews.llvm.org/D47157 rdar://problem/37077034 llvm-svn: 335375
* [hmaptool] Turn %hmaptool into a proper substitutionBenjamin Kramer2018-06-221-1/+1
| | | | | | | This is still super ugly, but at least it doesn't require working directories to just line up perfectly for python to find the tool. llvm-svn: 335330
* Re-apply: Add python tool to dump and construct header mapsBruno Cardoso Lopes2018-06-211-8/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Header maps are binary files used by Xcode, which are used to map header names or paths to other locations. Clang has support for those since its inception, but there's not a lot of header map testing around. Since it's a binary format, testing becomes pretty much brittle and its hard to even know what's inside if you don't have the appropriate tools. Add a python based tool that allows creating and dumping header maps based on a json description of those. While here, rewrite tests to use the tool and remove the binary files from the tree. This tool was initially written by Daniel Dunbar. Thanks to Stella Stamenova for helping make this work on Windows. Differential Revision: https://reviews.llvm.org/D46485 rdar://problem/39994722 llvm-svn: 335295
* Revert "Add python tool to dump and construct header maps"Bruno Cardoso Lopes2018-06-211-2/+8
| | | | | | | | | | | This reverts commit fcfa2dd517ec1a6045a81e8247e346d630a22618. Broke bots: http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/11315 http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/10411/steps/test-check-all/logs/stdio llvm-svn: 335196
* Revert "Warning for framework headers using double quote includes"Bruno Cardoso Lopes2018-06-2112-103/+0
| | | | | | | | | | | This reverts commit 9b5ff2db7e31c4bb11a7d468260b068b41c7c285. Broke bots: http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/11315 http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/10411/steps/test-check-all/logs/stdio llvm-svn: 335195
* Warning for framework headers using double quote includesBruno Cardoso Lopes2018-06-2012-0/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce -Wquoted-include-in-framework-header, which should fire a warning whenever a quote include appears in a framework header and suggest a fix-it. For instance, for header A.h added in the tests, this is how the warning looks like: ./A.framework/Headers/A.h:2:10: warning: double-quoted include "A0.h" in framework header, expected angle-bracketed instead [-Wquoted-include-in-framework-header] #include "A0.h" ^~~~~~ <A/A0.h> ./A.framework/Headers/A.h:3:10: warning: double-quoted include "B.h" in framework header, expected angle-bracketed instead [-Wquoted-include-in-framework-header] #include "B.h" ^~~~~ <B.h> This helps users to prevent frameworks from using local headers when in fact they should be targetting system level ones. The warning is off by default. Differential Revision: https://reviews.llvm.org/D47157 rdar://problem/37077034 llvm-svn: 335184
* Add python tool to dump and construct header mapsBruno Cardoso Lopes2018-06-201-8/+2
| | | | | | | | | | | | | | | | | | | | | | | Header maps are binary files used by Xcode, which are used to map header names or paths to other locations. Clang has support for those since its inception, but there's not a lot of header map testing around. Since it's a binary format, testing becomes pretty much brittle and its hard to even know what's inside if you don't have the appropriate tools. Add a python based tool that allows creating and dumping header maps based on a json description of those. While here, rewrite tests to use the tool and remove the binary files from the tree. This tool was initially written by Daniel Dunbar. Differential Revision: https://reviews.llvm.org/D46485 rdar://problem/39994722 llvm-svn: 335177
* [Modules] Improve .Private fix-its to handle 'explicit' and 'framework'Bruno Cardoso Lopes2018-06-153-1/+22
| | | | | | | | | | When in the context of suggestion the fix-it from .Private to _Private for private modules, trim off the 'explicit' and add 'framework' when appropriate. rdar://problem/41030554 llvm-svn: 334859
* Change return value of trivial visibility check.Richard Trieu2018-06-071-0/+15
| | | | | | | | | Previous, if no Decl's were checked, visibility was set to false. Switch it so that in cases of no Decl's, return true. These are the Decl's after being filtered. Also remove an unreachable return statement since it is directly after another return statement. llvm-svn: 334160
OpenPOWER on IntegriCloud