summaryrefslogtreecommitdiffstats
path: root/clang/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* PR41991: Accept attributes on defaulted and deleted friends.Richard Smith2020-01-301-1/+1
| | | | | | | Attributes are permitted on friend definitions, but we only checked for a proper function body, not for the =default / =delete cases. (cherry picked from commit 5ae6554a1dcd2e39346030c06d364492901c9e8d)
* [Concepts] Add 'this' context to instantiation of member requires clauseSaar Raz2020-01-301-0/+3
| | | | | | 'this' context was missing in instantiation of member requires clause. (cherry picked from commit 60f5da79e3de49b2074446e656a72970499a8d78)
* [Concepts] Add check for dependent RC when checking function constraintsSaar Raz2020-01-302-7/+6
| | | | | | | Do not attempt to check a dependent requires clause in a function constraint (may be triggered by, for example, DiagnoseUseOfDecl). (cherry picked from commit a424ef99e7b9821ec80564af3d3a8f091323a38c)
* [Concept] Fix incorrect check for containsUnexpandedParameterPack in CSESaar Raz2020-01-302-21/+50
| | | | | | | | | | We previously checked for containsUnexpandedParameterPack in CSEs by observing the property in the converted arguments of the CSE. This may not work if the argument is an expanded type-alias that contains a pack-expansion (see added test). Check the as-written arguments when determining containsUnexpandedParameterPack and isInstantiationDependent. (cherry picked from commit c83d9bedc0cc430dc620e7a807daeb985d390325)
* [CUDA] Assume the latest known CUDA version if we've found an unknown one.Artem Belevich2020-01-293-32/+21
| | | | | | | | | | | | | | | | | This makes clang somewhat forward-compatible with new CUDA releases without having to patch it for every minor release without adding any new function. If an unknown version is found, clang issues a warning (can be disabled with -Wno-cuda-unknown-version) and assumes that it has detected the latest known version. CUDA releases are usually supersets of older ones feature-wise, so it should be sufficient to keep released clang versions working with minor CUDA updates without having to upgrade clang, too. Differential Revision: https://reviews.llvm.org/D73231 (cherry picked from commit 12fefeef203ab4ef52d19bcdbd4180608a4deae1)
* [RISCV] Pass target-abi via module flag metadataZakk Chen2020-01-271-0/+7
| | | | | | | | | | | | Reviewers: lenary, asb Reviewed By: lenary Tags: #clang Differential Revision: https://reviews.llvm.org/D72755 (cherry picked from commit e15fb06e2d0a068de549464d72081811e7fac612)
* [Concepts] Fix incorrect TemplateArgs for introduction of local parametersSaar Raz2020-01-271-4/+3
| | | | | | | The wrong set of TemplateArgs was being provided to addInstantiatedParametersToScope. Caused bug #44658. (cherry picked from commit 9c24fca2a33fc0fd059e278bb95c84803dfff9ae)
* [Concepts] Add missing null check to transformConstructorSaar Raz2020-01-271-2/+4
| | | | | | Caused bug 44671 when transforming a constructor with a type-constraint with no explicit template args. (cherry picked from commit a8d096aff6b1930ad57bd0c30077d2b4920b5025)
* [Concepts] Fix parsing of scope specifier in compound-requirements, add more ↵Saar Raz2020-01-261-20/+6
| | | | | | | | | | | tests for scope specifiers in type-constraints The code for parsing of type-constraints in compound-requirements was not adapted for the new TryAnnotateTypeConstraint which caused compound-requirements with scope specifiers to ignore them. Also add regression tests for scope specifiers in type-constraints in more contexts. (cherry picked from commit 5043962dd3150c6ac72b75174b9460a510d1b5c3)
* [Concepts] Transform constraints of non-template functions to ConstantEvaluatedSaar Raz2020-01-256-46/+59
| | | | | | | | | | We would previously try to evaluate atomic constraints of non-template functions as-is, and since they are now unevaluated at first, this would cause incorrect evaluation (bugs #44657, #44656). Substitute into atomic constraints of non-template functions as we would atomic constraints of template functions, in order to rebuild the expressions in a constant-evaluated context. (cherry picked from commit 713562f54858f10bf8998ee21ff2c7e7bad0d177)
* [CUDA] Fix order of memcpy arguments in __shfl_*(<64-bit type>).Artem Belevich2020-01-241-2/+2
| | | | | | Wrong argument order resulted in broken shfl ops for 64-bit types. (cherry picked from commit cc14de88da27a8178976972bdc8211c31f7ca9ae)
* [Driver][CodeGen] Support -fpatchable-function-entry=N,M and ↵Fangrui Song2020-01-244-12/+22
| | | | | | | | | | __attribute__((patchable_function_entry(N,M))) where M>0 Reviewed By: nickdesaulniers Differential Revision: https://reviews.llvm.org/D73072 (cherry picked from commit 69bf40c45fd7f6dfe11b47de42571d8bff5ef94f)
* [Concepts] Make constraint expressions unevaluated until satisfaction checkingSaar Raz2020-01-242-7/+5
| | | | | | | | | As per P1980R0, constraint expressions are unevaluated operands, and their constituent atomic constraints only become constant evaluated during satisfaction checking. Change the evaluation context during parsing and instantiation of constraints to unevaluated. (cherry picked from commit 73eaf62463b4a29adf4194685af12d1a5d172987)
* [Concepts] Deprecate -fconcepts-ts, enable Concepts under -std=c++2aSaar Raz2020-01-247-18/+13
| | | | | | | | | Now with concepts support merged and mostly complete, we do not need -fconcepts-ts (which was also misleading as we were not implementing the TS) and can enable concepts features under C++2a. A warning will be generated if users still attempt to use -fconcepts-ts. (cherry picked from commit 67c608a9695496cfc9d3fdf9d0b12b554ac6b4df)
* [Concepts] Implement P1616R1 - Using unconstrained template template ↵Saar Raz2020-01-241-0/+5
| | | | | | | | | | | | | | | | parameters with constrained templates Summary: Allow unconstrained template template parameters to accept constrainted templates as arguments. Reviewers: rsmith Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D73155 (cherry picked from commit d42d5eb8ea77b3a3a502a60ba3f053fb81a897f3)
* [Concepts] Add ExpressionEvaluationContexts to instantiation of constraintsSaar Raz2020-01-241-0/+8
| | | | | | | Proper ExpressionEvaluationContext were not being entered when instantiating constraint expressions, which caused assertion failures in certain cases, including bug #44614. (cherry picked from commit 4d33a8dfcf67e970ea4d150d514b27de02e79aee)
* [Concepts] Placeholder constraints and abbreviated templatesSaar Raz2020-01-2430-273/+1078
| | | | | | | | | | | | | | | | | | | | | | | This patch implements P1141R2 "Yet another approach for constrained declarations". General strategy for this patch was: - Expand AutoType to include optional type-constraint, reflecting the wording and easing the integration of constraints. - Replace autos in parameter type specifiers with invented parameters in GetTypeSpecTypeForDeclarator, using the same logic previously used for generic lambdas, now unified with abbreviated templates, by: - Tracking the template parameter lists in the Declarator object - Tracking the template parameter depth before parsing function declarators (at which point we can match template parameters against scope specifiers to know if we have an explicit template parameter list to append invented parameters to or not). - When encountering an AutoType in a parameter context we check a stack of InventedTemplateParameterInfo structures that contain the info required to create and accumulate invented template parameters (fields that were already present in LambdaScopeInfo, which now inherits from this class and is looked up when an auto is encountered in a lambda context). Resubmit after fixing MSAN failures caused by incomplete initialization of AutoTypeLocs in TypeSpecLocFiller. Differential Revision: https://reviews.llvm.org/D65042 (cherry picked from commit b481f028144ca91c15d1db3649ce14f174259e7e)
* [Concepts] Profile TypeConstraints in ProfileTemplateParameterListSaar Raz2020-01-241-1/+4
| | | | | | | | | | | Profile TypeConstraints in ProfileTemplateParameterList so we can distinguish between partial specializations which differ in their TemplateParameterList type constraints. Recommit, now profiling the IDC so that we can deal with situations where the TemplateArgsAsWritten are nullptr (happens when canonicalizing type constraints). (cherry picked from commit 62c221b5090c2e1d3ca408bcab6f69c4d9e175b7)
* [Concepts] Fix bug when referencing function parameters in instantiated ↵Saar Raz2020-01-241-3/+3
| | | | | | | | function template requires clause Fixes bug #44613 - incorrect instantiated parameters were being added when checking instantiated function constraints (cherry picked from commit c2a250e1c43c05925fe040dc9624403af7879453)
* [Concepts] Fix incorrect recovery in TryAnnotateTypeConstraintSaar Raz2020-01-241-1/+4
| | | | | | | TryAnnotateTypeConstraint would not put the scope specifier back into the token stream when faced with a non-concept name after a scope specifier. (cherry picked from commit de51559fa68049da73b696a4e89468154b12852a)
* [Concepts] Fix circular AST->Sema dependency in ASTConcept.cppSaar Raz2020-01-241-1/+4
| | | | | | Remove inappropriate Sema include in ASTConcept.cpp introduced by D72552 for the finer-grained includes actually needed. (cherry picked from commit bb9b964072eb42a09e76fe148b36eefcfff077b2)
* [Concepts] Constraint Satisfaction CachingSaar Raz2020-01-244-32/+72
| | | | | | | | | | | Add a simple cache for constraint satisfaction results. Whether or not this simple caching would be permitted in final C++2a is currently being discussed but it is required for acceptable performance so we use it in the meantime, with the possibility of adding some cache invalidation mechanisms later. Differential Revision: https://reviews.llvm.org/D72552 (cherry picked from commit b933d37cd3774e5431b35e82187eebb59b1ff59e)
* [Concepts] Fix name-type conflict compilation issuesSaar Raz2020-01-241-4/+4
| | | | | | | | D50360 caused some platforms to not compile due to a parameter with the name of a type. Rename the parameter. (cherry picked from commit e68c1e00eba4ae64d38e62eebebd581e3d3d6bd4)
* [Concepts] Requires ExpressionsSaar Raz2020-01-2438-196/+1881
| | | | | | | | | | Implement support for C++2a requires-expressions. Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair. Differential Revision: https://reviews.llvm.org/D50360 (cherry picked from commit a0f50d731639350c7a79f140f026c27a18215531)
* Remove redundant CXXScopeSpec from TemplateIdAnnotation.Richard Smith2020-01-249-121/+128
| | | | | | | | | | | | | | A TemplateIdAnnotation represents only a template-id, not a nested-name-specifier plus a template-id. Don't make a redundant copy of the CXXScopeSpec and store it on the template-id annotation. This slightly improves error recovery by more properly handling the case where we would form an invalid CXXScopeSpec while parsing a typename specifier, instead of accidentally putting the token stream into a broken "annot_template_id with a scope specifier, but with no preceding annot_cxxscope token" state. (cherry picked from commit a42fd84cff265b7e9faa3fe42885ee171393e4db)
* [Concepts] Fix ConceptSpecializationExpr profiling crashSaar Raz2020-01-241-3/+3
| | | | | | | | | | | | ConceptSpecializationExprs (CSEs) were being created with nullptr TemplateArgsAsWritten during TemplateTemplateParmDecl canonicalization, and we were relying on them during profiling which caused sporadic crashes in test/CXX/.../temp.arg.template/p3-2a.cpp introduced in D44352. Change profiling of CSEs to instead rely on the actual converted template arguments and concept named. (cherry picked from commit 8a3446746098ba29348bb8f85357dd0b466a6d6e)
* [Sema] Avoid Wrange-loop-analysis false positivesMark de Wever2020-01-231-0/+6
| | | | | | | | | | | | | | | | When Wrange-loop-analysis issues a diagnostic on a dependent type in a template the diagnostic may not be valid for all instantiations. Therefore the diagnostic is suppressed during the instantiation. Non dependent types still issue a diagnostic. The same can happen when using macros. Therefore the diagnostic is disabled for macros. Fixes https://bugs.llvm.org/show_bug.cgi?id=44556 Differential Revision: https://reviews.llvm.org/D73007 (cherry picked from commit 41fcd17250fa0526e4b7fd2c7df7721b0f79b683)
* [PATCH] Reland [Clang] Un-break scan-build after integrated-cc1 changeAlexandre Ganea2020-01-222-2/+2
| | | | | | | | | | | | The issue was reported by @xazax.hun here: https://reviews.llvm.org/D69825#1827826 "This patch (D69825) breaks scan-build-py which parses the output of "-###" to get -cc1 command. There might be other tools with the same problems. Could we either remove (in-process) from CC1Command::Print or add a line break? Having the last line as a valid invocation is valuable and there might be tools relying on that." Differential Revision: https://reviews.llvm.org/D72982 (cherry picked from commit 133a7e631cee97965e310f0d110739217427fd3d)
* [HIP] use GetProgramPath for executable discoveryHolger Wünsche2020-01-221-15/+8
| | | | | | | | | | | This change replaces the manual building of executable paths using llvm::sys::path::append with GetProgramPath. This enables adding other paths in case executables reside in different directories and makes the code easier to read. Differential Revision: https://reviews.llvm.org/D72903 (cherry picked from commit 24d7a0935bea390fc444f6ac8cf02447fe8d6917)
* [clang-format] Expand the SpacesAroundConditions option to include catch ↵mydeveloperday2020-01-211-1/+1
| | | | | | | | | | | | | | statements Summary: This diff expands the SpacesAroundConditions option added in D68346 to include adding spaces to catch statements. Reviewed By: MyDeveloperDay Patch by: timwoj Differential Revision: https://reviews.llvm.org/D72793 (cherry picked from commit ea2be452542c81b04621e26c0d5e83be565f07e2)
* Revert 9007f06af0e "Revert "Allow system header to provide their own ↵Hans Wennborg2020-01-173-1/+21
| | | | | | | implementation of some builtin"" This should no longer be necessary after cd4c65f91d5 "Add __warn_memset_zero_len builtin as a workaround for glibc issue"
* Revert "Allow system header to provide their own implementation of some builtin"Amy Huang2020-01-173-21/+1
| | | | | | | | | This reverts commit 921f871ac438175ca8fcfcafdfcfac4d7ddf3905 because it causes libc++ code to trigger __warn_memset_zero_len. See https://reviews.llvm.org/D71082. (cherry picked from commit 3d210ed3d1880c615776b07d1916edb400c245a6)
* Revert "[OPENMP]Do not use RTTI by default for NVPTX devices."Alexey Bataev2020-01-171-2/+1
| | | | | | | This reverts commit 23058f9dd4d7e18239fd63b6da52549514b45fda. It breaks builds of cuda code somehow in some cases. (cherry picked from commit 6b29aa21180cf14bfb619d38fc4826913cabfb66)
* Add __warn_memset_zero_len builtin as a workaround for glibc issueserge-sans-paille2020-01-171-0/+2
| | | | | | | | | Glibc issue: https://sourceware.org/bugzilla/show_bug.cgi?id=25399 The fix consist in considering the missing function as a builtin lowered to a nop. Differential Revision: https://reviews.llvm.org/D72869 (cherry picked from commit d293417931d3a9d46799b42795988ca3b5cfd766)
* PR42694 Support explicit(bool) in older language modes as an extension.Richard Smith2020-01-173-12/+66
| | | | | | | | This needs somewhat careful disambiguation, as C++2a explicit(bool) is a breaking change. We only enable it in cases where the source construct could not possibly be anything else. (cherry picked from commit 45d70806f4386adfb62b0d75949a8aad58e0576f)
* Fix pack deduction to only deduce the arity of packs that are actuallyRichard Smith2020-01-171-20/+30
| | | | | | | | | | expanded by the deduced pack. We recently started also deducing the arity of separately-expanded packs that are merely mentioned within the pack in question, which is incorrect. (cherry picked from commit e8f198dd9e9dabed8d50276465906e7c8827cada)
* Work around PR43337: don't try to use the vec_sel overloads for vector long ↵Richard Smith2020-01-171-2/+2
| | | | | | long, since clang's <altivec.h> doesn't provide it yet! (cherry picked from commit 388eaa1270c2762d61b756759b6db8cf15bd3a83)
* Replace CLANG_SPAWN_CC1 env var with a driver mode flagNico Weber2020-01-161-0/+4
| | | | | | | | | | | | | | | | | | Flags are clang's default UI is flags. We can have an env var in addition to that, but in D69825 nobody has yet mentioned why this needs an env var, so omit it for now. If someone needs to set the flag via env var, the existing CCC_OVERRIDE_OPTIONS mechanism works for it (set CCC_OVERRIDE_OPTIONS=+-fno-integrated-cc1 for example). Also mention the cc1-in-process change in the release notes. Also spruce up the test a bit so it actually tests something :) Differential Revision: https://reviews.llvm.org/D72769 (cherry picked from commit 8e5018e990b701391e6c33ba85b012343df67272)
* [Lexer] Allow UCN for dollar symbol '\u0024' in identifiers when using ↵Scott Egerton2020-01-151-0/+2
| | | | | | | | | | | | | | | | | | | | -fdollars-in-identifiers flag. Summary: Previously, the -fdollars-in-identifiers flag allows the '$' symbol to be used in an identifier but the universal character name equivalent '\u0024' is not allowed. This patch changes this, so that \u0024 is valid in identifiers. Reviewers: rsmith, jordan_rose Reviewed By: rsmith Subscribers: dexonsmith, simoncook, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71758
* Revert "[RISCV] Add Clang frontend support for Bitmanip extension"Scott Egerton2020-01-153-12/+1
| | | | This reverts commit 57cf6ee9c84434161088c39a6f8dd2aae14eb12d.
* [Driver][X86] Add -malign-branch* and -mbranches-within-32B-boundariesFangrui Song2020-01-141-2/+55
| | | | | | | | These driver options perform some checking and delegate to MC options -x86-align-branch* and -x86-branches-within-32B-boundaries. Reviewed By: skan Differential Revision: https://reviews.llvm.org/D72463
* [ODRHash] Fix wrong error message with bitfields and mutable.Weverything2020-01-141-8/+16
| | | | | Add a check to bitfield mismatches that may have caused Clang to give an error about the bitfield instead of being mutable.
* Relax the rules around objc_alloc and objc_alloc_init optimizations.Pierre Habouzit2020-01-141-21/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Today the optimization is limited to: - `[ClassName alloc]` - `[self alloc]` when within a class method However it means that when code is written this way: ``` @interface MyObject - (id)copyWithZone:(NSZone *)zone { return [[self.class alloc] _initWith...]; } @end ``` ... then the optimization doesn't kick in and `+[NSObject alloc]` ends up in IMP caches where it could have been avoided. It turns out that `+alloc` -> `+[NSObject alloc]` is the most cached SEL/IMP pair in the entire platform which is rather silly). There's two theoretical risks allowing this optimization: 1. if the receiver is nil (which it can't be today), but it turns out that `objc_alloc()`/`objc_alloc_init()` cope with a nil receiver, 2. if the `Clas` type for the receiver is a lie. However, for such a code to work today (and not fail witn an unrecognized selector anyway) you'd have to have implemented the `-alloc` **instance method**. Fortunately, `objc_alloc()` doesn't assume that the receiver is a Class, it basically starts with a test that is similar to `if (receiver->isa->bits & hasDefaultAWZ) { /* fastpath */ }`. This bit is only set on metaclasses by the runtime, so if an instance is passed to this function by accident, its isa will fail this test, and `objc_alloc()` will gracefully fallback to `objc_msgSend()`. The one thing `objc_alloc()` doesn't support is tagged pointer instances. None of the tagged pointer classes implement an instance method called `'alloc'` (actually there's a single class in the entire Apple codebase that has such a method). Differential Revision: https://reviews.llvm.org/D71682 Radar-Id: rdar://problem/58058316 Reviewed-By: Akira Hatanaka Signed-off-by: Pierre Habouzit <phabouzit@apple.com>
* PR44540: Prefer an inherited default constructor over an initializerRichard Smith2020-01-142-39/+45
| | | | | | | | | list constructor when initializing from {}. We would previously pick between calling an initializer list constructor and calling a default constructor unstably in this situation, depending on whether the inherited default constructor had already been used elsewhere in the program.
* [Concepts] Type ConstraintsSaar Raz2020-01-1520-209/+864
| | | | | | | Add support for type-constraints in template type parameters. Also add support for template type parameters as pack expansions (where the type constraint can now contain an unexpanded parameter pack). Differential Revision: https://reviews.llvm.org/D44352
* [X86] ABI compat bugfix for MSVC vectorcallReid Kleckner2020-01-141-75/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this change, X86_32ABIInfo::classifyArgument would be called twice on vector arguments to vectorcall functions. This function has side effects to track GPR register usage, and this would lead to incorrect GPR usage in some cases. The specific case I noticed is from running out of XMM registers with mixed FP and vector arguments and no aggregates of any kind. Consider this prototype: void __vectorcall vectorcall_indirect_vec( double xmm0, double xmm1, double xmm2, double xmm3, double xmm4, __m128 xmm5, __m128 ecx, int edx, __m128 mem); classifyArgument has no effects when called on a plain FP type, but when called on a vector type, it modifies FreeRegs to model GPR consumption. However, this should not happen during the vector call first pass. I refactored the code to unify vectorcall HVA logic with regcall HVA logic. The conventions pass HVAs in registers differently (expanded vs. not expanded), but if they do not fit in registers, they both pass them indirectly by address. Reviewers: erichkeane, craig.topper Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D72110
* Allow /D flags absent during PCH creation under msvc-compatZachary Henkel2020-01-141-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this patch adding a new /D flag when compiling a source file that consumed a PCH with clang-cl would issue a diagnostic and then fail. With the patch, the diagnostic is still issued but the definition is accepted. This matches the msvc behavior. The fuzzy-pch-msvc.c is a clone of the existing fuzzy-pch.c tests with some msvc specific rework. msvc diagnostic: warning C4605: '/DBAR=int' specified on current command line, but was not specified when precompiled header was built Output of the CHECK-BAR test prior to the code change: <built-in>(1,9): warning: definition of macro 'BAR' does not match definition in precompiled header [-Wclang-cl-pch] #define BAR int ^ D:\repos\llvm\llvm-project\clang\test\PCH\fuzzy-pch-msvc.c(12,1): error: unknown type name 'BAR' BAR bar = 17; ^ D:\repos\llvm\llvm-project\clang\test\PCH\fuzzy-pch-msvc.c(23,4): error: BAR was not defined # error BAR was not defined ^ 1 warning and 2 errors generated. Reviewers: rnk, thakis, hans, zturner Subscribers: mikerice, aganea, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D72405
* [remark][diagnostics] Using clang diagnostic handler for IR input filesRong Xu2020-01-141-17/+76
| | | | | | | | | | | | | | | | | | | | | | | | For IR input files, we currently use LLVM diagnostic handler even the compilation is from clang. As a result, we are not able to use -Rpass to get the transformation reports. Some warnings are not handled properly either: We found many mysterious warnings in our ThinLTO backend compilations in SamplePGO and CSPGO. An example of the warning: "warning: net/proto2/public/metadata_lite.h:51:21: 0.02% (1 / 4999)" This turns out to be a warning by Wmisexpect, which is supposed to be filtered out by default. But since the filter is in clang's diagnostic hander, we emit these incomplete warnings from LLVM's diagnostic handler. This patch uses clang diagnostic handler for IR input files. We create a fake backendconsumer just to install the diagnostic handler. With this change, we will have proper handling of all the warnings and we can use -Rpass* options in IR input files compilation. Also note that with is patch, LLVM's diagnostic options, like "-mllvm -pass-remarks=*", are no longer be able to get optimization remarks. Differential Revision: https://reviews.llvm.org/D72523
* [OPENMP]Do not use RTTI by default for NVPTX devices.Alexey Bataev2020-01-141-1/+2
| | | | NVPTX does not support RTTI, so disable it by default.
* make -fmodules-codegen and -fmodules-debuginfo work also with PCHsLuboš Luňák2020-01-154-11/+27
| | | | | | | | | | Allow to build PCH's (with -building-pch-with-obj and the extra .o file) with -fmodules-codegen -fmodules-debuginfo to allow emitting shared code into the extra .o file, similarly to how it works with modules. A bit of a misnomer, but the underlying functionality is the same. This saves up to 20% of build time here. Differential Revision: https://reviews.llvm.org/D69778
OpenPOWER on IntegriCloud