summaryrefslogtreecommitdiffstats
path: root/clang/test/Modules
Commit message (Collapse)AuthorAgeFilesLines
* [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
* [ODRHash] Adjust info stored for FunctionTemplateDecl.Richard Trieu2018-06-071-0/+14
| | | | | | | Avoid storing information for definitions since those can be out-of-line and vary between modules even when the declarations are the same. llvm-svn: 334151
* [Modules] Warning for module declarations lacking 'framework' qualifierBruno Cardoso Lopes2018-06-014-0/+17
| | | | | | | | | | | | | | | When a module declaration for a framework lacks the 'framework' qualifier, the listed headers aren't found (because there's no trigger for the special framework style path lookup) and the module is silently not built. This leads to frameworks not being modularized by accident, which is pretty bad. Add a warning and suggest the user to add the 'framework' qualifier when we can prove that it's the case. rdar://problem/39193062 llvm-svn: 333718
* [ODRHash] Support FunctionTemplateDecl in records.Richard Trieu2018-05-301-0/+439
| | | | llvm-svn: 333486
* Improve diagnostics for config mismatches with -fmodule-file.Richard Smith2018-05-242-7/+6
| | | | | | | | Unless the user uses -Wno-module-file-config-mismatch (or -Wno-error=...), allow the AST reader to produce errors describing the nature of the config mismatch. llvm-svn: 333220
* Track the result of evaluating a computed noexcept specification on theRichard Smith2018-05-031-0/+34
| | | | | | | | | | | | | | FunctionProtoType. We previously re-evaluated the expression each time we wanted to know whether the type is noexcept or not. We now evaluate the expression exactly once. This is not quite "no functional change": it fixes a crasher bug during AST deserialization where we would try to evaluate the noexcept specification in a situation where we have not deserialized sufficient portions of the AST to permit such evaluation. llvm-svn: 331428
* [Modules] Allow @import to reach submodules in private module mapsBruno Cardoso Lopes2018-05-026-0/+18
| | | | | | | | | | | | | | | | | | | | A @import targeting a top level module from a private module map file (@import Foo_Private), would fail if there's any submodule declaration around (module Foo.SomeSub) in the same private module map. This happens because compileModuleImpl, when building Foo_Private, will start with the private module map and will not parse the public one, which leads to unsuccessful parsing of Foo.SomeSub, since top level Foo was never parsed. Declaring other submodules in the private module map is not common and should usually be avoided, but it shouldn't fail to build. Canonicalize compileModuleImpl to always look at the public module first, so that all necessary information is available when parsing the private one. rdar://problem/39822328 llvm-svn: 331322
* [Modules] Fix testcases from r331232Bruno Cardoso Lopes2018-04-302-3/+2
| | | | llvm-svn: 331233
* [Modules] Handle ObjC/C ODR-like semantics for EnumConstantDeclBruno Cardoso Lopes2018-04-305-0/+24
| | | | | | | | | | | | | | Support for ObjC/C ODR-like semantics with structural equivalence checking was added back in r306918. There enums are handled and also checked for structural equivalence. However, at use time of EnumConstantDecl, support was missing for preventing ambiguous name lookup. Add the missing bits for properly merging EnumConstantDecl. rdar://problem/38374569 llvm-svn: 331232
* [Modules][ObjC] ASTReader should add protocols for class extensionsBruno Cardoso Lopes2018-04-275-0/+37
| | | | | | | | | | | | During deserialization clang is currently missing the merging of protocols into the canonical interface for the class extension. This merging only currently happens during parsing and should also be considered during deserialization. rdar://problem/38724303 llvm-svn: 331063
* [ODRHash] Hash template arguments of methods.Richard Trieu2018-04-251-1/+104
| | | | llvm-svn: 330789
* Add some infuriatingly necessary comments to this test case.Chandler Carruth2018-04-174-0/+12
| | | | | | | | | | | | | | | | | | | | | | Without these comments, by "luck" the contents of SomeKit's SKWidget.h are precisely the same as SomeKitCore's SomeKitCore.h. This can create havoc if anything canonicalizes on the inode and your filesystem assigns a common inode to files with identical file content. Alternatively, if your build system uses symlinks into a content-addressed-storage (as Google's does), you end up with these files being symlinks to the same file. The end result is that Clang deduplicates them internally, and then believes that the SomeKit framework includes the SomeKitCore.h header, and does not include the SKWidget.h in SomeKit. This in turn results in warnings in this test and eventually errors as Clang becomes confused because the umbrella header for SomeKitCore has already been included into another framework's module (SomeKit). Yay. If anyone has a better idea about how to avoid this, I'm all ears. Nothing other than causing the file content to change worked for me. llvm-svn: 330184
* Use export_as for autolinking frameworksBruno Cardoso Lopes2018-04-1611-0/+77
| | | | | | | | | | | | | | | | framework module SomeKitCore { ... export_as SomeKit } Given the module above, while generting autolink information during codegen, clang should to emit '-framework SomeKitCore' only if SomeKit was not imported in the relevant TU, otherwise it should use '-framework SomeKit' instead. rdar://problem/38269782 llvm-svn: 330152
* [ODRHash] Support pointer and reference types.Richard Trieu2018-04-131-0/+121
| | | | | | | Recommit r328404 which was reverted in rL328404. r329869 fixed the issue that caused the revert. llvm-svn: 330074
* [ODRHash] Skip more types hashing TypedefTypeRichard Trieu2018-04-121-0/+32
| | | | | | To get the underlying type for TypedefType's, also skip ElaboratedType's. llvm-svn: 329869
* [PATCH] [RISCV] Extend getTargetDefines for RISCVTargetInfoShiva Chen2018-04-052-0/+45
| | | | | | | | | | | | | | Summary: This patch extend getTargetDefines and implement handleTargetFeatures and hasFeature. and define corresponding marco for those features. Reviewers: asb, apazos, eli.friedman Differential Revision: https://reviews.llvm.org/D44727 Patch by Kito Cheng. llvm-svn: 329278
* Temporarily revert r328404:Eric Christopher2018-04-021-122/+0
| | | | | | | | | | | | | | commit 519b97132a4c960e8dedbfe4290d86970d92e995 Author: Richard Trieu <rtrieu@google.com> Date: Sat Mar 24 00:52:44 2018 +0000 [ODRHash] Support pointer and reference types. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@328404 91177308-0d34-0410-b5e6-96231b3b80d8 As it's breaking some tests. I've communicated with Richard offline about testcases. llvm-svn: 329001
* [Modules] Improve fixit for framework private module mapsBruno Cardoso Lopes2018-03-301-1/+1
| | | | | | | | | The wrong source range was being provided in some case, fix that to get a better fixit. rdar://problem/38520199 llvm-svn: 328857
* [ODRHash] Support pointer and reference types.Richard Trieu2018-03-241-0/+122
| | | | llvm-svn: 328404
* [Modules] Update test to mention it requires C++14.Volodymyr Sapsai2018-03-231-1/+1
| | | | llvm-svn: 328283
* [Modules] Fix creating fake definition data for lambdas.Volodymyr Sapsai2018-03-213-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During reading C++ definition data for lambda we can access CXXRecordDecl representing lambda before we finished reading the definition data. This can happen by reading a captured variable which is VarDecl, then reading its decl context which is CXXMethodDecl `operator()`, then trying to merge redeclarable methods and accessing enclosing CXXRecordDecl. The call stack looks roughly like VisitCXXRecordDecl ReadCXXRecordDefinition VisitVarDecl VisitCXXMethodDecl mergeRedeclarable getPrimaryContextForMerging If we add fake definition data at this point, later we'll hit the assertion Assertion failed: (!DD.IsLambda && !MergeDD.IsLambda && "faked up lambda definition?"), function MergeDefinitionData, file clang/lib/Serialization/ASTReaderDecl.cpp, line 1675. The fix is to assign definition data before reading it. Fixes PR32556. rdar://problem/37461072 Reviewers: rsmith, bruno Reviewed By: rsmith Subscribers: cfe-commits, jkorous-apple, aprantl Differential Revision: https://reviews.llvm.org/D43494 llvm-svn: 328153
* [Modules] Honor -fmodule-name when handling private framework modulesBruno Cardoso Lopes2018-03-206-0/+21
| | | | | | | | | | | | | | | | When skipping building the module for a private framework module, LangOpts.CurrentModule isn't enough for implict modules builds; for instance, in case a private module is built while building a public one, LangOpts.CurrentModule doesn't reflect the -fmodule-name being passed down, but instead the module name which triggered the build. Store the actual -fmodule-name in LangOpts.ModuleName and actually check a name was provided during compiler invocation in order to skip building the private module. rdar://problem/38434694 llvm-svn: 328053
* [ObjC] Allow declaring __weak pointer fields in C structs in ARC.Akira Hatanaka2018-03-194-0/+39
| | | | | | | | | | | | | | | | | | | This patch uses the infrastructure added in r326307 for enabling non-trivial fields to be declared in C structs to allow __weak fields in C structs in ARC. This recommits r327206, which was reverted because it caused module-enabled builders to fail. I discovered that the CXXRecordDecl::CanPassInRegisters flag wasn't being set correctly in some cases after I moved it to RecordDecl. Thanks to Eric Liu for helping me investigate the bug. rdar://problem/33599681 https://reviews.llvm.org/D44095 llvm-svn: 327870
OpenPOWER on IntegriCloud