summaryrefslogtreecommitdiffstats
path: root/clang/test/Modules/Inputs
Commit message (Collapse)AuthorAgeFilesLines
* [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
* [Modules] Implement ODR-like semantics for tag types in C/ObjCBruno Cardoso Lopes2017-07-014-0/+34
| | | | | | | | | | | | | | | | | | | | | | Allow ODR for ObjC/C in the sense that we won't keep more that one definition around (merge them). However, ensure the decl pass the structural compatibility check in C11 6.2.7/1, for that, reuse the structural equivalence checks used by the ASTImporter. Few other considerations: - Create error diagnostics for tag types mismatches and thread them into the structural equivalence checks. - Note that by doing this we only support redefinition between types that are considered "compatible types" by C. This is mixed approach of the suggestions discussed in http://lists.llvm.org/pipermail/cfe-dev/2017-March/053257.html Differential Revision: https://reviews.llvm.org/D31778 rdar://problem/31909368 llvm-svn: 306918
* [ASTReader] Add test for previous change r306583 / 145692e.Graydon Hoare2017-06-294-0/+12
| | | | | | | | | | | | | | | | | | | | Summary: Add a test for the change to ASTReader that reproduces the logic for consolidating multiple ObjC interface definitions to the case of multiple ObjC protocol definitions. This test is a modified copy of the test that accompanied the original change to interfaces, in 2ba1979. Reviewers: bruno Reviewed By: bruno Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D34788 llvm-svn: 306732
* Track the set of module maps read while building a .pcm file and reload ↵Richard Smith2017-06-295-0/+5
| | | | | | those when preprocessing from that .pcm file. llvm-svn: 306628
OpenPOWER on IntegriCloud