summaryrefslogtreecommitdiffstats
path: root/clang
Commit message (Collapse)AuthorAgeFilesLines
* [Concepts] Deprecate -fconcepts-ts, enable Concepts under -std=c++2aSaar Raz2020-01-2457-77/+72
| | | | | | | | | 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-242-5/+10
| | | | | | | | | | | | | | | | 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-242-0/+20
| | | | | | | 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-2453-362/+1871
| | | | | | | | | | | | | | | | | | | | | | | 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-242-1/+21
| | | | | | | | | | | 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-242-3/+13
| | | | | | | | 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-2410-55/+144
| | | | | | | | | | | 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-2466-302/+3811
| | | | | | | | | | 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-2416-152/+153
| | | | | | | | | | | | | | 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)
* [Clang][IFS][Test] Work around in-process cc1 ASAN issues #2.Mitch Phillips2020-01-231-4/+12
| | | | | | | | | | | | | Using the same strategy as c38e42527b21. D69825 revealed (introduced?) a problem when building with ASan, and some memory leaks somewhere. More details are available in the original patch. Looks like we missed one failing tests, this patch adds the workaround to this test as well. (cherry picked from commit e174da447c180b586719cb28f7bd556e30625762)
* [clang][IFS][test] Temporary work around for in-process cc1 ASAN issues.Puyan Lotfi2020-01-232-1/+19
| | | | | | | | | | | | | | When using in-process cc1, the Clang Interface Stubs pipeline setup exposes an ASAN bug. I am still investigating this issue but want to green the bots for now. I don't think this is a huge issue since the Clang Interface Stubs Driver setup code is the only code path that sets up such a pipeline (ie N cc1's for N c files followed by another N cc1's for to generate stub files for the same N c files). This issue is being discussed in https://reviews.llvm.org/D69825. If a resolution is not found soon, a bugzilla filling will be in order. (cherry picked from commit c38e42527b21acee8d01a016d5bfa2fb83202e29)
* Update documentation and release notes to match the state ofRichard Smith2020-01-232-16/+26
| | | | -flax-vector-conversions on the Clang 10 release branch.
* Revert "PR17164: Change clang's default behavior from ↵Mitch Phillips2020-01-2310-40/+23
| | | | | | | | | | | | -flax-vector-conversions=all to -flax-vector-conversions=integer." This patch broke the Sanitizer buildbots. Please see the commit's differential revision for more information (https://reviews.llvm.org/D67678). This reverts commit b72a8c65e4e34779b6bc9e466203f553f5294486. (cherry picked from commit edd4398f4cd33a305afbca76ac4e6590e9337f4d)
* [Sema] Avoid Wrange-loop-analysis false positivesMark de Wever2020-01-232-0/+78
| | | | | | | | | | | | | | | | 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)
* Clang] Fix expansion of response files in -Wp after integrated-cc1 changeAlexandre Ganea2020-01-233-10/+24
| | | | | | | | | | After rGb4a99a061f517e60985667e39519f60186cbb469, passing a response file such as -Wp,@a.rsp wasn't working anymore because .rsp expansion happens inside clang's main() function. This patch adds response file expansion in the -cc1 tool. Differential Revision: https://reviews.llvm.org/D73120 (cherry picked from commit 68d7f06092e56b17eb0cddf560a9d9fe8afb7dd8)
* Revert "[cmake] Fix clang builds with BUILD_SHARED=ON and ↵Tom Stellard2020-01-231-9/+1
| | | | | | | | | | | CLANG_LINK_CLANG_DYLIB=ON" This reverts commit df839cfda09dbadc26b8be635f27da75f1f27190. This change used cmake's list filter operation which was not added until cmake 3.6. (cherry picked from commit 4751e4f8c24bc07fdb668dc49ee559b97c1e3c22)
* [cmake] Fix clang builds with BUILD_SHARED=ON and CLANG_LINK_CLANG_DYLIB=ONTom Stellard2020-01-231-1/+9
| | | | | | | | | | | | | | | | | | | Summary: We were linking all the clang objects and shared libraries into libclang-cpp.so, which was causing the command line options to be registered twice. Reviewers: beanz, mgorny Reviewed By: beanz, mgorny Subscribers: mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68520 (cherry picked from commit df839cfda09dbadc26b8be635f27da75f1f27190)
* [PATCH] Reland [Clang] Un-break scan-build after integrated-cc1 changeAlexandre Ganea2020-01-226-9/+10
| | | | | | | | | | | | 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-212-1/+2
| | | | | | | | | | | | | | 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-176-1/+58
| | | | | | | 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-176-58/+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-172-22/+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-173-0/+12
| | | | | | | | | 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)
* Add extra test file forgotten in 45d7080.Richard Smith2020-01-171-0/+62
| | | | (cherry picked from commit b78e8e0d79c47a6698a0abc10a37b8a253cb6064)
* PR42694 Support explicit(bool) in older language modes as an extension.Richard Smith2020-01-176-16/+91
| | | | | | | | 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-172-20/+48
| | | | | | | | | | 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)
* PR17164: Change clang's default behavior from -flax-vector-conversions=all ↵Richard Smith2020-01-1711-23/+64
| | | | | | | | | | | | | | | | | | to -flax-vector-conversions=integer. Summary: See proposal on cfe-dev: http://lists.llvm.org/pipermail/cfe-dev/2019-April/062030.html Reviewers: SjoerdMeijer, eli.friedman Subscribers: kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67678 (cherry picked from commit b72a8c65e4e34779b6bc9e466203f553f5294486)
* 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-165-28/+62
| | | | | | | | | | | | | | | | | | 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)
* Fix Wdocumentation warning. NFC.Simon Pilgrim2020-01-151-2/+0
|
* [Lexer] Allow UCN for dollar symbol '\u0024' in identifiers when using ↵Scott Egerton2020-01-152-2/+3
| | | | | | | | | | | | | | | | | | | | -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-154-19/+1
| | | | This reverts commit 57cf6ee9c84434161088c39a6f8dd2aae14eb12d.
* Fix up ms-pch-macro.c test to pass on non-WindowsReid Kleckner2020-01-141-5/+5
|
* [Driver][X86] Add -malign-branch* and -mbranches-within-32B-boundariesFangrui Song2020-01-145-2/+114
| | | | | | | | 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-142-9/+33
| | | | | 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-142-22/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-143-39/+59
| | | | | | | | | 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.
* Modify test to use -S instead of -c so that it works when an external ↵Douglas Yung2020-01-141-4/+4
| | | | assembler is used that is not present.
* [Concepts] Type ConstraintsSaar Raz2020-01-1540-315/+1566
| | | | | | | 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-143-81/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-142-1/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix windows bot failures in c410adb092c9cb51ddb0b55862b70f2aa8c5b16fRong Xu2020-01-141-1/+1
| | | | (clang diagnostic handler for IR input files)
* [remark][diagnostics] Using clang diagnostic handler for IR input filesRong Xu2020-01-145-18/+132
| | | | | | | | | | | | | | | | | | | | | | | | 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-142-1/+22
| | | | NVPTX does not support RTTI, so disable it by default.
* make -fmodules-codegen and -fmodules-debuginfo work also with PCHsLuboš Luňák2020-01-156-11/+60
| | | | | | | | | | 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