summaryrefslogtreecommitdiffstats
path: root/clang/test/Modules/Inputs
Commit message (Collapse)AuthorAgeFilesLines
* Modules: Search for a visible definition of the decl context when computing ↵David Blaikie2019-04-1913-0/+62
| | | | | | | | | | | | | | | | | | | | | | | | | visibility of a default template parameter The code is/was already correct for the case where a parameter is a parameter of its enclosing lexical DeclContext (functions and classes). But for other templates (alias and variable templates) they don't create their own scope to be members of - in those cases, they parameter should be considered visible if any definition of the lexical decl context is visible. [this should cleanup the failure on the libstdc++ modules buildbot] [this doesn't actually fix the variable template case for a secondary/compounding reason (its lexical decl context is incorrectly considered to be the translation unit)] Test covers all 4 kinds of templates with default args, including a regression test for the still broken variable template case. Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D60892 llvm-svn: 358795
* Modules: Invalidate out-of-date PCMs as they're discoveredDuncan P. N. Exon Smith2019-03-098-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Leverage the InMemoryModuleCache to invalidate a module the first time it fails to import (and to lock a module as soon as it's built or imported successfully). For implicit module builds, this optimizes importing deep graphs where the leaf module is out-of-date; see example near the end of the commit message. Previously the cache finalized ("locked in") all modules imported so far when starting a new module build. This was sufficient to prevent loading two versions of the same module, but was somewhat arbitrary and hard to reason about. Now the cache explicitly tracks module state, where each module must be one of: - Unknown: module not in the cache (yet). - Tentative: module in the cache, but not yet fully imported. - ToBuild: module found on disk could not be imported; need to build. - Final: module in the cache has been successfully built or imported. Preventing repeated failed imports avoids variation in builds based on shifting filesystem state. Now it's guaranteed that a module is loaded from disk exactly once. It now seems safe to remove FileManager::invalidateCache, but I'm leaving that for a later commit. The new, precise logic uncovered a pre-existing problem in the cache: the map key is the module filename, and different contexts use different filenames for the same PCM file. (In particular, the test Modules/relative-import-path.c does not build without this commit. r223577 started using a relative path to describe a module's base directory when importing it within another module. As a result, the module cache sees an absolute path when (a) building the module or importing it at the top-level, and a relative path when (b) importing the module underneath another one.) The "obvious" fix is to resolve paths using FileManager::getVirtualFile and change the map key for the cache to a FileEntry, but some contexts (particularly related to ASTUnit) have a shorter lifetime for their FileManager than the InMemoryModuleCache. This is worth pursuing further in a later commit; perhaps by tying together the FileManager and InMemoryModuleCache lifetime, or moving the in-memory PCM storage into a VFS layer. For now, use the PCM's base directory as-written for constructing the filename to check the ModuleCache. Example ======= To understand the build optimization, first consider the build of a module graph TU -> A -> B -> C -> D with an empty cache: TU builds A' A' builds B' B' builds C' C' builds D' imports D' B' imports C' imports D' A' imports B' imports C' imports D' TU imports A' imports B' imports C' imports D' If we build TU again, where A, B, C, and D are in the cache and D is out-of-date, we would previously get this build: TU imports A imports B imports C imports D (out-of-date) TU builds A' A' imports B imports C imports D (out-of-date) builds B' B' imports C imports D (out-of-date) builds C' C' imports D (out-of-date) builds D' imports D' B' imports C' imports D' A' imports B' imports C' imports D' TU imports A' imports B' imports C' imports D' After this commit, we'll immediateley invalidate A, B, C, and D when we first observe that D is out-of-date, giving this build: TU imports A imports B imports C imports D (out-of-date) TU builds A' // The same graph as an empty cache. A' builds B' B' builds C' C' builds D' imports D' B' imports C' imports D' A' imports B' imports C' imports D' TU imports A' imports B' imports C' imports D' The new build matches what we'd naively expect, pretty closely matching the original build with the empty cache. rdar://problem/48545366 llvm-svn: 355778
* Modules: Add -Rmodule-importDuncan P. N. Exon Smith2019-03-065-0/+10
| | | | | | | | | | | | | | | | | | Add a remark for importing modules. Depending on whether this is a direct import (into the TU being built by this compiler instance) or transitive import (into an already-imported module), the diagnostic has two forms: importing module 'Foo' from 'path/to/Foo.pcm' importing module 'Foo' into 'Bar' from 'path/to/Foo.pcm' Also drop a redundant FileCheck invocation in Rmodule-build.m that was using -Reverything, since the notes from -Rmodule-import were confusing it. https://reviews.llvm.org/D58891 llvm-svn: 355477
* [HeaderSearch] loadSubdirectoryModuleMaps should respect -working-directoryAlex Lorenz2018-11-142-0/+6
| | | | | | | | | | | Include search paths can be relative paths. The loadSubdirectoryModuleMaps function should account for that and respect the -working-directory parameter given to Clang. rdar://46045849 Differential Revision: https://reviews.llvm.org/D54503 llvm-svn: 346822
* Debug Info (-gmodules): emit full types for non-anchored template ↵Adrian Prantl2018-10-244-0/+81
| | | | | | | | | | | | | | | | | specializations Before this patch, clang would emit a (module-)forward declaration for template instantiations that are not anchored by an explicit template instantiation, but still are guaranteed to be available in an imported module. Unfortunately detecting the owning module doesn't reliably work when local submodule visibility is enabled and the template is inside a cross-module namespace. This make clang debuggable again with -gmodules and LSV enabled. rdar://problem/41552377 llvm-svn: 345109
* Fix an assert in -Wquoted-include-in-framework-headerErik Pilkington2018-09-202-0/+2
| | | | | | | | Fixes rdar://43692300 Differential revision: https://reviews.llvm.org/D52253 llvm-svn: 342679
* [modules] Frontend support for building a header module from a list ofRichard Smith2018-09-152-0/+9
| | | | | | 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
* When we leave a module header, make that header visible in itsRichard Smith2018-09-124-0/+30
| | | | | | includer's context, even if its overall module is unavailable. llvm-svn: 342096
* Reapply r336660: [Modules] Autoload subdirectory modulemaps with specific ↵Bruno Cardoso Lopes2018-07-185-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "[modules] Fix 37878; Autoload subdirectory modulemaps with specific ↵Bruno Cardoso Lopes2018-07-125-23/+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-105-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Add protocol redefinition to the current scope/contextBruno Cardoso Lopes2018-06-304-0/+17
| | | | | | | | | | | | 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
* [ODRHash] Do not rely on Type* when computing the hash.Vassil Vassilev2018-06-285-0/+34
| | | | | | | | | | | | | | | | | 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][ObjC] Warn on the use of '@import' in framework headersBruno Cardoso Lopes2018-06-273-0/+8
| | | | | | | | | | | 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
* Warning for framework include violation from Headers to PrivateHeadersBruno Cardoso Lopes2018-06-2512-0/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-2211-0/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Warning for framework headers using double quote includes"Bruno Cardoso Lopes2018-06-2111-64/+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-2011-0/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Modules] Improve .Private fix-its to handle 'explicit' and 'framework'Bruno Cardoso Lopes2018-06-152-0/+12
| | | | | | | | | | 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
* [Modules] Warning for module declarations lacking 'framework' qualifierBruno Cardoso Lopes2018-06-013-0/+6
| | | | | | | | | | | | | | | 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
* [Modules] Allow @import to reach submodules in private module mapsBruno Cardoso Lopes2018-05-025-0/+11
| | | | | | | | | | | | | | | | | | | | 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-301-1/+0
| | | | llvm-svn: 331233
* [Modules] Handle ObjC/C ODR-like semantics for EnumConstantDeclBruno Cardoso Lopes2018-04-304-0/+14
| | | | | | | | | | | | | | 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-274-0/+28
| | | | | | | | | | | | 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
* 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-1610-0/+33
| | | | | | | | | | | | | | | | 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
* [PATCH] [RISCV] Extend getTargetDefines for RISCVTargetInfoShiva Chen2018-04-051-0/+5
| | | | | | | | | | | | | | 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
* [Modules] Fix creating fake definition data for lambdas.Volodymyr Sapsai2018-03-212-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-205-0/+15
| | | | | | | | | | | | | | | | 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-193-0/+29
| | | | | | | | | | | | | | | | | | | 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
* 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
* [ODRHash] Fix hashing for friend functions.Richard Trieu2018-02-223-0/+42
| | | | | | | When hashing a templated function, use the hash of the function it was instantiated from. llvm-svn: 325742
* [Modules] Add more language features to be used with requires-declarationBruno Cardoso Lopes2018-02-141-0/+18
| | | | | | | | | Features added: c99, c11, c17, cplusplus14 and cplusplus17. rdar://problem/36328787 rdar://problem/36668431 llvm-svn: 325154
* [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
* [modules] Fix incorrect diagnostic mapping computation when a module changesRichard Smith2018-02-091-0/+3
| | | | | | | | | | | | | | | 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
* [ODRHash] Don't hash friend functions.Richard Trieu2018-01-125-0/+47
| | | | | | | | 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
* Test case for r321396Richard Trieu2018-01-0610-0/+63
| | | | | | | | 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
* Reapply r321781: [Modules] Allow modules specified by -fmodule-map-file to ↵Bruno Cardoso Lopes2018-01-0513-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0413-49/+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-0413-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* -gmodules: Emit debug info for implicit module imports via #include.Adrian Prantl2018-01-031-0/+3
| | | | | | | | | | | | 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
* [Modules] Change private modules rules and warningsBruno Cardoso Lopes2017-12-2211-0/+22
| | | | | | | | | | | | | | | | 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
* Modular Codegen: Don't home always_inline functionsDavid Blaikie2017-11-022-0/+6
| | | | | | | | 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
* [Module map] Introduce a private module re-export directive.Douglas Gregor2017-09-141-0/+9
| | | | | | | | | | | | | Introduce a new "export_as" directive for top-level modules, which indicates that the current module is a "private" module whose symbols will eventually be exported through the named "public" module. This is in support of a common pattern in the Darwin ecosystem where a single public framework is constructed of several private frameworks, with (currently) header duplication and some support from the linker. Addresses rdar://problem/34438420. llvm-svn: 313316
* Revert "[Modules] Prevent #import to reenter header if not building a module."Bruno Cardoso Lopes2017-08-121-6/+0
| | | | | | | This reverts commit r310605. Richard pointed out a better way to achieve this, which I'll post a patch for soon. llvm-svn: 310775
* [modules] Set the lexical DC for dummy tag decls that refer to hiddenAlex Lorenz2017-08-112-0/+15
| | | | | | | | | | | | | | declarations that are made visible after the dummy is parsed and ODR verified Prior to this commit the "(getContainingDC(DC) == CurContext && "The next DeclContext should be lexically contained in the current one.")," assertion failure was triggered during semantic analysis of the dummy tag declaration that was declared in another tag declaration because its lexical context did not point to the outer tag decl. rdar://32292196 llvm-svn: 310706
* [Modules] Prevent #import to reenter header if not building a module.Bruno Cardoso Lopes2017-08-101-0/+6
| | | | | | | | | | When non-modular headers are imported while not building a module but in -fmodules mode, be conservative and preserve the default #import semantic: do not reenter headers. rdar://problem/33745031 llvm-svn: 310605
* Debug Info: Avoid completing class types when a definition is in a module.Adrian Prantl2017-07-241-3/+3
| | | | | | | | | | This patch adds an early exit to CGDebugInfo::completeClassData() when compiling with -gmodules and the to-be-completed type is available in a clang module. rdar://problem/23599990 llvm-svn: 308938
* Update for LLVM IR metadata changes (DIImportedEntity now needs a DIFile).Adrian Prantl2017-07-192-0/+8
| | | | | | | | | <rdar://problem/33357889> https://bugs.llvm.org/show_bug.cgi?id=33822 Differential Revision: https://reviews.llvm.org/D35583 llvm-svn: 308399
OpenPOWER on IntegriCloud