summaryrefslogtreecommitdiffstats
path: root/clang/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix a reentrance bug with deserializing ObjC type parameters.John McCall2020-02-131-1/+1
| | | | | | | | | | | | | This is a longstanding bug that seems to have been hidden by a combination of (1) the normal flow being to deserialize the interface before deserializing its parameter and (2) a precise ordering of work that was apparently recently disturbed, perhaps by my abstract-serialization work or Bruno's ObjC module merging work. Fixes rdar://59153545. (cherry picked from commit 77b2ffc498e92cce7546d191f6712a3046300501)
* Fix type-dependency of bitfields in templatesElizabeth Andrews2020-02-131-0/+5
| | | | | | | | | | | | | This patch is a follow up to 878a24ee244a24. Name of bitfields with value-dependent width should be set as type-dependent. This patch adds the required value-dependency check and sets the type-dependency accordingly. Patch fixes PR44886 Differential revision: https://reviews.llvm.org/D72242 (cherry picked from commit a58017e5cae5be948fd1913b68d46553e87aa622)
* [Concepts] Add missing TPA commit to requires expression parsingSaar Raz2020-02-121-0/+1
| | | | | | | | | | If an error had occurred when annotating a scope spec during the tentative parse for a type-requirement, we would not revert nor commit the tentative parse, triggerring an assertion failure. Commit the TPA in this case and then do error recovery. (cherry picked from commit 271e495399170d69627c1acd591c9298cb0b5b4b)
* [Concepts] Do not check constraints if not all template arguments have been ↵Saar Raz2020-02-121-6/+9
| | | | | | | | | | | | | deduced We previously checked the constraints of instantiated function templates even in cases where PartialOverloading was true and not all template arguments have been deduced, which caused crashes in clangd (bug 44714). We now check if all arguments have been deduced before checking constraints in partial overloading scenarios. (cherry picked from commit 5fef14d932fe602bf998b8fb8a809ff85ca1e245)
* [X86] Cast to __v4hi instead of __m64 in the implementation of ↵Craig Topper2020-02-121-2/+2
| | | | | | | | | | | _mm_extract_pi16 and _mm_insert_pi16. __m64 is a vector of 1 long long. But the builtins these intrinsics are calling expect a vector of 4 shorts. Fixes PR44589 (cherry picked from commit 16b9410caa35da976fa5f3cf6dd3d6f3776d51ca)
* [OpenCL] Restrict addr space conversions in nested pointersAnastasia Stulova2020-02-122-10/+32
| | | | | | | | | | | | | | | | | | | | | | Address space conversion changes pointer representation. This commit disallows such conversions when they are not legal i.e. for the nested pointers even with compatible address spaces. Because the address space conversion in the nested levels can't be generated to modify the pointers correctly. The behavior implemented is as follows: - Any implicit conversions of nested pointers with different address spaces is rejected. - Any conversion of address spaces in nested pointers in safe casts (e.g. const_cast or static_cast) is rejected. - Conversion in low level C-style or reinterpret_cast is accepted but with a warning (this aligns with OpenCL C behavior). Fixes PR39674 Differential Revision: https://reviews.llvm.org/D73360 (cherry picked from commit 6064f426a18304e16b51cc79e74c9c2d55ef5a9c)
* Prefer __vector over vector keyword for altivecserge-sans-paille2020-02-111-2/+2
| | | | | | | | | | | `vector' uses the keyword-and-predefine mode from gcc, while __vector is reliably supported. As a side effect, it also makes the code consistent in its usage of __vector. Differential Revision: https://reviews.llvm.org/D74129 (cherry picked from commit 3185c30c54d0af5bffbff3bcfd721668d086ff10)
* Re-land "[Clang][Driver] Remove -M group options ..." and "[Clang] Avoid ↵Alexandre Ganea2020-02-104-12/+35
| | | | | | | | | | | crashing when generating crash diagnostics when '#pragma clang __debug ..." This re-lands commits f41ec709d9d388dc43469e6ac7f51b6313f7e4af (https://reviews.llvm.org/D74076) and commit 5fedc2b410853a6aef05e8edf19ebfc4e071e28f (https://reviews.llvm.org/D74070) The previous build break was caused by '#pragma clang __debug llvm_unreachable' used in a non-assert build. Move it to a separate test in crash-report-with-asserts.c. (cherry picked from commit 75f09b54429bee17a96e2ba7a2ac0f0a8a7f7e74)
* [Clang] Remove unused #pragma clang __debug handle_crashAlexandre Ganea2020-02-101-5/+0
| | | | | | | | | As discussed in D70568, remove this because it isn't used anywhere, and I think it's better to go through real crashes for testing (#pragma clang __debug crash). Also remove the support function llvm::CrashRecoveryContext::HandleCrash() which was added at the same time by @ddunbar. Differential Revision: https://reviews.llvm.org/D74063 (cherry picked from commit 8ecde3ac34bbb5a8d53d8ec5cd32867658646df1)
* [analyzer] Fix a couple of bugs in HTML report generation.Artem Dergachev2020-02-101-1/+10
| | | | | | | | It should now produce valid HTML again. Differential Revision: https://reviews.llvm.org/D73993 (cherry picked from commit 482e236e569e8324f70778af1eb756923cd490dc)
* [Concepts] Fix incorrect check when instantiating abbreviated template ↵Saar Raz2020-02-062-2/+36
| | | | | | | | | | | | | type-constraints We would incorrectly check whether the type-constraint had already been initialized, causing us to ignore the invented template type constraints entirely. Also, TemplateParameterList would store incorrect information about invented type parameters when it observed them before their type-constraint was initialized, so we recreate it after initializing the function type of an abbreviated template. (cherry picked from commit 38fd69995fc5a6f16e0aa132a46e5ccdbc2eebb3)
* Don't warn about missing declarations for partial template specializationsAaron Puchert2020-02-051-0/+1
| | | | | | | | | | Summary: Just like templates, they are excepted from the ODR rule. Reviewed By: aaron.ballman, rsmith Differential Revision: https://reviews.llvm.org/D68923 (cherry picked from commit 27684ae66d5545f211c0ac4393d0ba2bf3b5b47c)
* PR44786: Don't assert when profiling <=> expressions.Richard Smith2020-02-041-2/+2
| | | | (cherry picked from commit b96c6b65b93f7b3878bced2374bef747a4c3b690)
* [Concepts] Add missing CXXThisScope to function template constraint substitutionSaar Raz2020-02-052-1/+14
| | | | | | | | | | We did not have a CXXThisScope around constraint checking of functions and function template specializations, causing a crash when checking a constraint that had a 'this' (bug 44689). Recommit after fixing test. (cherry picked from commit 6c232441564f8934477e418347bf0c217abb0a00)
* PR44721: Don't consider overloaded operators for built-in comparisonsRichard Smith2020-02-041-7/+22
| | | | | | | | | | | | | | | | | | | | when building a defaulted comparison. As a convenient way of asking whether `x @ y` is valid and building it, we previouly always performed overload resolution and built an overloaded expression, which would both end up picking a builtin operator candidate when given a non-overloadable type. But that's not quite right, because it can result in our finding a user-declared operator overload, which we should never do when applying operators non-overloadable types. Handle this more correctly: skip overload resolution when building `x @ y` if the operands are not overloadable. But still perform overload resolution (considering only builtin candidates) when checking validity, as we don't have any other good way to ask whether a binary operator expression would be valid. (cherry picked from commit 1f3f8c369a5067a132c871f33a955a7feaea8534)
* PR44761: Fix fallback to later tiebreakers if two non-template functionsRichard Smith2020-02-041-8/+6
| | | | | | are equally constrained. (cherry picked from commit cfacf9ae20b8c97a428f118a2720bc109ba6a143)
* [Concepts] Instantiate invented template type parameter type-constraint ↵Saar Raz2020-02-032-20/+155
| | | | | | | | | | | | | | | | | along with function parameters We previously instantiated type-constraints of template type parameters along with the type parameter itself, this caused problems when the type-constraints created by abbreviated templates refreneced other parameters in the abbreviated templates. When encountering a template type parameter with a type constraint, if it is implicit, delay instantiation of the type-constraint until the function parameter which created the invented template type parameter is instantiated. Reland after fixing bug caused by another flow reaching SubstParmVarDecl and instantiating the TypeConstraint a second time. (cherry picked from commit 84959ae47f447fca9d56a9c61e8c46e993d0387a)
* Revert "[Concepts] Instantiate invented template type parameter ↵Saar Raz2020-02-032-150/+20
| | | | | | type-constraint along with function parameters" This temporarily reverts commit 2b54b8b994b45d4e0a72f36dfb91dc9662543234 which caused some test failures.
* [Concepts] Instantiate invented template type parameter type-constraint ↵Saar Raz2020-02-032-20/+150
| | | | | | | | | | | | | | along with function parameters We previously instantiated type-constraints of template type parameters along with the type parameter itself, this caused problems when the type-constraints created by abbreviated templates refreneced other parameters in the abbreviated templates. When encountering a template type parameter with a type constraint, if it is implicit, delay instantiation of the type-constraint until the function parameter which created the invented template type parameter is instantiated. (cherry picked from commit eacca4824463d8b96e2e1c9f8bbf886055218a16)
* Fix wrong devirtualization when the final overrider in one base classRichard Smith2020-01-312-4/+30
| | | | | | overrides the final overrider in a different base class. (cherry picked from commit aade5fbbfef3e8555df202082bea905deebc2ca5)
* PR44723: Trigger return type deduction for operator<=>s whose returnRichard Smith2020-01-311-0/+25
| | | | | | | | | | types are needed to compute the return type of a defaulted operator<=>. This raises the question of what to do if return type deduction fails. The standard doesn't say, and implementations vary, so for now reject that case eagerly to keep our options open. (cherry picked from commit 42d4a55f227a1cc78ab8071062d869abe88655d9)
* [Concepts] Fix isDeclarationSpecifier to detect type-constraints correctlySaar Raz2020-01-311-3/+8
| | | | | | | | | isDeclarationSpecifiers did not handle some cases of placeholder-type-specifiers with type-constraints, causing parsing bugs in abbreviated constructor templates. Add comprehensive handling of type-constraints to isDeclarationSpecifier. (cherry picked from commit b7ce85a130789d23c69156f4b899962458d1f05d)
* [Concepts] Correctly form initial parameter mapping for parameter packs, ↵Saar Raz2020-01-313-21/+48
| | | | | | | | | | | | support substitution into SubstNonTypeTemplateParmExpr We previously would not correctly for the initial parameter mapping for variadic template parameters in Concepts. Testing this lead to the discovery that with the normalization process we would need to substitute into already-substituted-into template arguments, which means we need to add NonTypeTemplateParmExpr support to TemplateInstantiator. We do that by substituting into the replacement and the type separately, and then re-checking the expression against the NTTP with the new type, in order to form any new required implicit casts (for cases where the type of the NTTP was dependent). (cherry picked from commit ba1f3db4b0729ad932aa4f091e9578132d98a0c8)
* PR44627: Consider reversing == and <=> candidates found by ADL.Richard Smith2020-01-301-8/+22
| | | | (cherry picked from commit 1db66e705f4dbe7dbe17edac804289ef59d5f616)
* [Concepts] Check function constraints before deducing auto return typeSaar Raz2020-01-311-24/+24
| | | | | | | | | | A constrained function with an auto return type would have it's definition instantiated in order to deduce the auto return type before the constraints are checked. Move the constraints check after the return type deduction. (cherry picked from commit 980517b3530ffb7faa1a23fdc007d78f5b45ae3c)
* 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)
OpenPOWER on IntegriCloud