| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
| |
This comes up when substituting into an already-substituted template
argument during constraint satisfaction checking.
(cherry picked from commit b20ab412bf838a8a87e5cc1c8c6399c3c9255354)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
| |
RequiresExprBodyDecl"
We're not planning more release candidates for 10.0.0 at the moment, so
reverting for now.
This reverts commit 9e0bd5ec03cbc8d53048e92ddf7fd25bca17e912.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
| |
deduction.
(cherry picked from commit 34bd51f4b1d9f489e61becb662bdc72bb56dd277)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
| |
type-constraint along with function parameters"
This temporarily reverts commit 2b54b8b994b45d4e0a72f36dfb91dc9662543234 which caused some test failures.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
| |
The wrong set of TemplateArgs was being provided to addInstantiatedParametersToScope.
Caused bug #44658.
(cherry picked from commit 9c24fca2a33fc0fd059e278bb95c84803dfff9ae)
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
| |
function template requires clause
Fixes bug #44613 - incorrect instantiated parameters were being added when checking instantiated function constraints
(cherry picked from commit c2a250e1c43c05925fe040dc9624403af7879453)
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Function trailing requires clauses now parsed, supported in overload resolution and when calling, referencing and taking the address of functions or function templates.
Differential Revision: https://reviews.llvm.org/D43357
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pack expansion.
Previously, if all parameter / argument pairs for a pack expansion
deduction were non-deduced contexts, we would not deduce the arity of
the pack, and could end up deducing a different arity (leading to
failures during substitution) or defaulting to an arity of 0 (leading to
bad diagnostics about passing the wrong number of arguments to a
variadic function). Instead, we now always deduce the arity for all
involved packs any time we deduce a pack expansion.
This will result in less substitution happening in some cases, which
could avoid non-SFINAEable errors, and should generally improve the
quality of diagnostics when passing initializer lists to variadic
functions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This adds parsing of the qualifiers __ptr32, __ptr64, __sptr, and __uptr and
lowers them to the corresponding address space pointer for 32-bit and 64-bit pointers.
(32/64-bit pointers added in https://reviews.llvm.org/D69639)
A large part of this patch is making these pointers ignore the address space
when doing things like overloading and casting.
https://bugs.llvm.org/show_bug.cgi?id=42359
Reviewers: rnk, rsmith
Subscribers: jholewinski, jvesely, nhaehnle, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D71039
|
|
|
|
| |
and comment lines.
|
|
|
|
|
|
|
| |
Disable the instantiation-depth-default.cpp test on NetBSD since it
requires more stack space than we have by default on NetBSD.
Differential Revision: https://reviews.llvm.org/D71419
|
|
|
|
|
|
|
|
|
|
|
|
| |
forming non-type template parameter values.
This reverts commit 93cc9dddd82f9e971f382ade6acf6634c5914966,
which reverted commit 11d10527852b4d3ed738aa90d8bec0f398160593.
We now always form `&x` when forming a pointer to a function rather than
trying to use function-to-pointer decay. This matches the behavior of
the old code in this case, but not the intent as described by the
comments.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 11d10527852b4d3ed738aa90d8bec0f398160593.
This change is problematic with function pointer template parameters. For
example, building libcxxabi with futexes (-D_LIBCXXABI_USE_FUTEX) produces this
diagnostic:
In file included from .../llvm-project/libcxxabi/src/cxa_guard.cpp:15:
.../llvm-project/libcxxabi/src/cxa_guard_impl.h:416:54: error: address of function 'PlatformThreadID' will always evaluate to 'true' [-Werror,-Wpointer-bool-conversion]
has_thread_id_support(this->thread_id_address && GetThreadIDArg),
~~ ^~~~~~~~~~~~~~
.../llvm-project/libcxxabi/src/cxa_guard.cpp:38:26: note: in instantiation of member function '__cxxabiv1::(anonymous namespace)::InitByteFutex<&__cxxabiv1::(anonymous namespace)::PlatformFutexWait, &__cxxabiv1::(anonymous namespace)::PlatformFutexWake, &__cxxabiv1::(anonymous namespace)::PlatformThreadID>::InitByteFutex' requested here
SelectedImplementation imp(raw_guard_object);
^
.../llvm-project/libcxxabi/src/cxa_guard_impl.h:416:54: note: prefix with the address-of operator to silence this warning
has_thread_id_support(this->thread_id_address && GetThreadIDArg),
^
&
1 error generated.
The diagnostic is incorrect: adding the address-of operator also fails ("cannot
take the address of an rvalue of type 'uint32_t (*)()' (aka 'unsigned int
(*)()')").
|
|
|
|
| |
forming non-type template parameter values.
|
|
|
|
|
| |
member function to a non-noexcept pointer to member non-type template
parameter.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch reapplies commit 759948467ea. Patch was reverted due to a
clang-tidy test fail on Windows. The test has been modified. There
are no additional code changes.
Patch was tested with ninja check-all on Windows and Linux.
Summary of code changes:
Clang currently crashes for switch statements inside a template when the
condition is a non-integer field member because contextual implicit
conversion is skipped when parsing the condition. This conversion is
however later checked in an assert when the case statement is handled.
The conversion is skipped when parsing the condition because
the field member is set as type-dependent based on its containing class.
This patch sets the type dependency based on the field's type instead.
This patch fixes Bug 40982.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: I agree with https://easyaspi314.github.io/gcc-vs-clang.html?fbclid=IwAR1VA0qxiWVUusOQUv5z7JESS7ZpeJy-UqAI5mnJscofGLqXcqeErIUB2gU, current warning message is not very good. We should try to improve it..
Reviewers: rsmith, aaron.ballman, easyaspi314
Reviewed By: aaron.ballman
Subscribers: arphaman, Quuxplusone, mehdi_amini, hiraditya, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D69762
|
|
|
|
|
|
|
| |
templates""
This reverts commit 759948467ea3181615d44d80f74ffeb260180fd0.
There were build bot failures in clang-tidy
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch reapplies commit 76945821b9cad3. The first version broke
buildbots due to clang-tidy test fails. The fails are because some
errors in templates are now diagnosed earlier (does not wait till
instantiation). I have modified the tests to add checks for these
diagnostics/prevent these diagnostics. There are no additional code
changes.
Summary of code changes:
Clang currently crashes for switch statements inside a template when the
condition is a non-integer field member because contextual implicit
conversion is skipped when parsing the condition. This conversion is
however later checked in an assert when the case statement is handled.
The conversion is skipped when parsing the condition because
the field member is set as type-dependent based on its containing class.
This patch sets the type dependency based on the field's type instead.
This patch fixes Bug 40982.
Reviewers: rnk, gribozavr2
Patch by: Elizabeth Andrews (eandrews)
Differential revision: https://reviews.llvm.org/D69950
|
|
|
|
|
|
|
|
| |
The issue was introduced by D33189 which fixed PR33189.
Fixes PR38671: "destructor cannot be declared as a template" leads to segfault in Sema::LookupSpecialMember
Differential Revision: https://reviews.llvm.org/D69225
|
| |
|
|
|
|
|
|
| |
defined as deleted.
The actual bug was fixed in commit d052a578.
|
|
|
|
| |
to the ambiguity, rather than noting all viable candidates.
|
|
|
|
|
|
|
|
|
|
| |
parameter type.
We were both failing to decay the array type to a pointer and failing to
remove the top-level cv-qualifications. Fix this by decaying array
parameters even if the parameter type is dependent.
llvm-svn: 374496
|