summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema
Commit message (Collapse)AuthorAgeFilesLines
* [clang] Fix crash on visiting null nestedNameSpecifier.Haojian Wu2020-06-101-1/+4
| | | | | | | | | | | | | | Summary: Fix https://github.com/clangd/clangd/issues/293 Reviewers: sammccall Subscribers: ilya-biryukov, kadircet, usaxena95, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D76320 (cherry picked from commit bd763e2cf7c1d84bab95064cc5cbe542b227b025)
* PR45063: Fix crash on invalid processing an elaborated class template-idRichard Smith2020-06-101-0/+3
| | | | | | with an invalid scope specifier. (cherry picked from commit 44c3a63c74dddeef17e424ec76bd90c8582d8a3c)
* PR45000: Let Sema::SubstParmVarDecl handle default args of lambdas in ↵Aaron Puchert2020-05-063-15/+2
| | | | | | | | | | | | | | | | | | | | initializers Summary: We extend the behavior for local functions and methods of local classes to lambdas in variable initializers. The initializer is not a separate scope, but we treat it as such. We also remove the (faulty) instantiation of default arguments in TreeTransform::TransformLambdaExpr, because it doesn't do proper initialization, and if it did, we would do it twice (and thus also emit eventual errors twice). Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D76038 (cherry picked from commit f43859a099fa3587123717be941fa63ba8d0d4f2)
* Teach TreeTransform to substitute into resolved TemplateArguments.Richard Smith2020-04-141-47/+38
| | | | | | | This comes up when substituting into an already-substituted template argument during constraint satisfaction checking. (cherry picked from commit b20ab412bf838a8a87e5cc1c8c6399c3c9255354)
* [Concepts] Fix incorrect control flow when TryAnnotateTypeConstraint ↵Saar Raz2020-03-191-5/+8
| | | | | | | | | | | | | annotates an invalid template-id TryAnnotateTypeConstraint could annotate a template-id which doesn't end up being a type-constraint, in which case control flow would incorrectly flow into ParseImplicitInt. Reenter the loop in this case. Enable relevant tests for C++20. This required disabling typo-correction during TryAnnotateTypeConstraint and changing a test case which is broken due to a separate bug (will be reported and handled separately). (cherry picked from commit 19fccc52ff2c1da1f93d9317c34769bd9bab8ac8)
* [Concepts] Fix incorrect DeclContext for transformed RequiresExprBodyDeclSaar Raz2020-03-191-1/+1
| | | | | | | | | We would assign the incorrect DeclContext when transforming the RequiresExprBodyDecl, causing incorrect handling of 'this' inside RequiresExprBodyDecls (bug #45162). Assign the current context as the DeclContext of the transformed decl. (cherry picked from commit 9769e1ee9acc33638449b50ac394b5ee2d4efb60)
* Revert "[Concepts] Fix incorrect DeclContext for transformed ↵Hans Wennborg2020-03-181-1/+1
| | | | | | | | | RequiresExprBodyDecl" We're not planning more release candidates for 10.0.0 at the moment, so reverting for now. This reverts commit 9e0bd5ec03cbc8d53048e92ddf7fd25bca17e912.
* Revert "[Concepts] Fix incorrect control flow when TryAnnotateTypeConstraint ↵Hans Wennborg2020-03-181-8/+5
| | | | | | | | | annotates an invalid template-id" We're not planning more release candidates for 10.0.0 at the moment, so reverting for now. This reverts commit 135744ce689569e7c64033bb5812572d3000239b.
* [Concepts] Fix incorrect control flow when TryAnnotateTypeConstraint ↵Saar Raz2020-03-171-5/+8
| | | | | | | | | | | | | annotates an invalid template-id TryAnnotateTypeConstraint could annotate a template-id which doesn't end up being a type-constraint, in which case control flow would incorrectly flow into ParseImplicitInt. Reenter the loop in this case. Enable relevant tests for C++20. This required disabling typo-correction during TryAnnotateTypeConstraint and changing a test case which is broken due to a separate bug (will be reported and handled separately). (cherry picked from commit 19fccc52ff2c1da1f93d9317c34769bd9bab8ac8)
* [Concepts] Fix incorrect DeclContext for transformed RequiresExprBodyDeclSaar Raz2020-03-171-1/+1
| | | | | | | | | We would assign the incorrect DeclContext when transforming the RequiresExprBodyDecl, causing incorrect handling of 'this' inside RequiresExprBodyDecls (bug #45162). Assign the current context as the DeclContext of the transformed decl. (cherry picked from commit 9769e1ee9acc33638449b50ac394b5ee2d4efb60)
* PR45083: Mark statement expressions as being dependent if they appear inRichard Smith2020-03-125-14/+78
| | | | | | | | | | | | | | | | a dependent context. This matches the GCC behavior. We track the enclosing template depth when determining whether a statement expression is within a dependent context; there doesn't appear to be any other reliable way to determine this. We previously assumed they were neither value- nor instantiation-dependent under any circumstances, which would lead to crashes and other misbehavior. (cherry picked from commit 5c845c1c50ac89a6f12557d1571678f3d1432478)
* Revert "PR45083: Mark statement expressions as being dependent if they ↵Hans Wennborg2020-03-123-20/+10
| | | | | | | | | appear in" This turned out to cause problems, and was reverted on master together with its follow-up change in 66addf8e803618758457e4d578c5084e322ca448. This reverts commit 3a843031a5ad83a00d2603f623881cb2b2bf719d.
* PR45124: Don't leave behind pending cleanups when declaring implicitRichard Smith2020-03-111-3/+9
| | | | | | | | | | | | | | deduction guides. Previously if an implicit deduction guide had a default argument with a cleanup, we'd leave the 'pending cleanup' flag set after declaring the implicit guide. But it turns out that there's no reason to even substitute into the default argument when declaring an implicit deduction guide: we only need to record that the default argument exists, not what it is, since we never actually form a call to a deduction guide. (cherry picked from commit 6d894afdea433879f54e5ba07e827db006645b7b)
* [Concepts] Add null check for TemplateTypeParmType::getDecl() in ↵Saar Raz2020-03-061-1/+1
| | | | | | | | | | | GetContainedInventedTypeParmVisitor GetContainedInventedTypeParmVisitor would not account for the case where TemplateTypeParmType::getDecl() is nullptr, causing bug #45102. Add the nullptr check. (cherry picked from commit 865456d589e093582acaafd17d58ad1c0cce66af)
* PR45083: Mark statement expressions as being dependent if they appear inRichard Smith2020-03-043-10/+20
| | | | | | | | | | dependent contexts. We previously assumed they were neither value- nor instantiation-dependent under any circumstances, which would lead to crashes and other misbehavior. (cherry picked from commit bdad0a1b79273733df9acc1be4e992fa5d70ec56)
* PR44890: Inherit explicitly-specified template arguments into base classRichard Smith2020-02-191-1/+1
| | | | | | deduction. (cherry picked from commit 34bd51f4b1d9f489e61becb662bdc72bb56dd277)
* [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)
* [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)
* [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)
* [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)
* 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] 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)
* [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)
* [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] Transform constraints of non-template functions to ConstantEvaluatedSaar Raz2020-01-255-44/+57
| | | | | | | | | | 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)
* [Driver][CodeGen] Support -fpatchable-function-entry=N,M and ↵Fangrui Song2020-01-241-2/+2
| | | | | | | | | | __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-241-5/+3
| | | | | | | | | 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-242-5/+5
| | | | | | | | | 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-2410-165/+593
| | | | | | | | | | | | | | | | | | | | | | | 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] 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] Constraint Satisfaction CachingSaar Raz2020-01-242-32/+60
| | | | | | | | | | | 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] Requires ExpressionsSaar Raz2020-01-2412-74/+975
| | | | | | | | | | 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-242-9/+7
| | | | | | | | | | | | | | 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)
* [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)
* 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)
* PR44540: Prefer an inherited default constructor over an initializerRichard Smith2020-01-141-2/+2
| | | | | | | | | 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-156-90/+350
| | | | | | | 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
* [OPENMP]Improve handling of possibly incorrectly mapped types.Alexey Bataev2020-01-141-2/+18
| | | | | Need to analayze the type of the expression for mapping, not the type of the declaration.
OpenPOWER on IntegriCloud