Like concepts checking, a trailing return type of a lambda
in a dependent context may refer to captures in which case
they may need to be rebuilt, so the map of local decl
should include captures.
This patch reveal a pre-existing issue.
`this` is always recomputed by TreeTransform.
`*this` (like all captures) only become `const`
after the parameter list.
However, if try to recompute the value of `this` (in a parameter)
during template instantiation while determining the type of the call operator,
we will determine it to be const (unless the lambda is mutable).
There is no good way to know at that point that we are in a parameter
or not, the easiest/best solution is to transform the type of this.
Note that doing so break a handful of HLSL tests.
So this is a prototype at this point.
Fixes#65067Fixes#63675
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D159126
Like concepts checking, a trailing return type of a lambda
in a dependent context may refer to captures in which case
they may need to be rebuilt, so the map of local decl
should include captures.
This patch reveal a pre-existing issue.
`this` is always recomputed by TreeTransform.
`*this` (like all captures) only become `const`
after the parameter list.
However, if try to recompute the value of `this` (in a parameter)
during template instantiation while determining the type of the call operator,
we will determine it to be const (unless the lambda is mutable).
There is no good way to know at that point that we are in a parameter
or not, the easiest/best solution is to transform the type of this.
Note that doing so break a handful of HLSL tests.
So this is a prototype at this point.
Fixes#65067Fixes#63675
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D159126
AST nodes that may depend on FP options keep them as a difference
relative to the options outside the AST node. At the moment of
instantiation the FP options may be different from the default values,
defined by command-line option. In such case FP attributes would have
unexpected values. For example, the code:
template <class C> void func_01(int last, C) {
func_01(last, int());
}
void func_02() { func_01(0, 1); }
#pragma STDC FENV_ACCESS ON
caused compiler crash, because template instantiation takes place at the
end of translation unit, where pragma STDC FENV_ACCESS is in effect. As
a result, code in the template instantiation would use constrained
intrinsics while the function does not have StrictFP attribute.
To solve this problem, FP attributes in Sema must be set to default
values, defined by command line options.
This change resolves https://github.com/llvm/llvm-project/issues/63542.
Differential Revision: https://reviews.llvm.org/D154359
This diff switches the approach to comparison of constraint expressions
to the new one based on template args substitution.
It continues the effort to fix our handling of out-of-line definitions
of constrained templates.
This is a recommit of 3a54022934.
Differential revision: https://reviews.llvm.org/D146178
Sema.h is huge. This makes a small reduction to it by moving
EnterExpressionEvaluationContext into a new header, since it is an
independent component.
Differential Revision: https://reviews.llvm.org/D149796
This diff switches the approach to comparison of constraint expressions
to the new one based on template args substitution.
It continues the effort to fix our handling of out-of-line definitions
of constrained templates.
This is a recommit of e3b1083e00.
Differential revision: https://reviews.llvm.org/D146178
This reverts commit e3b1083e00e62f5d157d15cb8c63a1c3dfdf12e2.
This was reverted because it breaks a number of libstdc++ examples, AND
required a workaround that causes hiding of legitimate bugs.
This diff switches the approach to comparison of constraint expressions
to the new one based on template args substitution.
It continues the effort to fix our handling of out-of-line definitions
of constrained templates.
This is a recommit of 60bee9ff5445.
Differential revision: https://reviews.llvm.org/D146178
This temporarily reverts commit
60bee9ff544541e83ffbd4be31923d0e8b644690.
The diff will be recommitted once the newly discovered
regressions are fixed.
PR D135370 implemented a performance improvement but it restricted the filtering
of declaration from inline namespace too much. In particular it did not filter
for the function template case.
This led to a regression and this PR removes that check.
This fixes: https://github.com/llvm/llvm-project/issues/61851
Differential Revision: https://reviews.llvm.org/D147762
This diff switches the approach to comparison of constraint expressions
to the new one based on template args substitution.
It continues the effort to fix our handling of out-of-line definitions
of constrained templates.
The associated GitHub issue: https://github.com/llvm/llvm-project/issues/61414
Test plan:
1/ ninja check-all
2/ bootstrapped Clang passes tests
Differential revision: https://reviews.llvm.org/D146178
Seemingly we never tested this, but the constraint on a NTTP was being
swtiched to the 'instantiated' version, but constraints need to be
relative to the 'top level', so this was causing us to not be able to
check the constraint on final use.
This patch corrects the issue by making the constraint created with the
un-instantiated version in the case of dependent constraint attachment.
Fixes: #61777
If a template function contained a pragma that made it strictfp, code
generation for such function crashed, because the instantiation did not
have strictfp attribute. As a solution this attribute is copied from the
template to instantiation.
Differential Revision: https://reviews.llvm.org/D143919
Closes https://github.com/llvm/llvm-project/issues/54457.
This removes a FIXME we found previously. But we didn't remove the FIXME
that time due to the lack of the corresponding test. And now we found
the corresponding test so we can remove it.
std::optional::value() has undesired exception checking semantics and is
unavailable in older Xcode (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS). The
call sites block std::optional migration.
This makes `ninja clang` work in the absence of llvm::Optional::value.
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
This revision fixes typos where there are 2 consecutive words which are
duplicated. There should be no code changes in this revision (only
changes to comments and docs). Do let me know if there are any
undesirable changes in this revision. Thanks.
template-template parameters. Although it effects whether a template can be
used as an argument for another template, the constraint seems not to
be checked, nor other major implementations (GCC, MSVC, et al.) check it.
Additionally, Part-A of the document seems to have been implemented.
So mark P0857R0 as completed.
Differential Revision: https://reviews.llvm.org/D134128
Implements the changes required to perform substitution with
non-canonical template arguments, and to 'finalize' them
by not placing 'Subst' nodes.
A finalized substitution means we won't resugar them later,
because these templates themselves were eagerly substituted
with the intended arguments at the point of use. We may still
resugar other templates used within those, though.
This patch does not actually implement any uses of this
functionality, those will be added in subsequent patches,
so expect no changes to existing tests.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D134604
Makes CheckTemplateArgumentList and the template deduction functions
produce a sugared converted argument list in addition to the canonical one.
This is mostly NFC except that we hook this up to a few diagnostics in
SemaOverload.
The infrastructure here will be used in subsequent patches
where we perform a finalized sugared substitution for entities
which we do not unique per specializations on canonical arguments,
and later on will be used for template specialization resugaring.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D133874
Implements the changes required to perform substitution with
non-canonical template arguments, and to 'finalize' them
by not placing 'Subst' nodes.
A finalized substitution means we won't resugar them later,
because these templates themselves were eagerly substituted
with the intended arguments at the point of use. We may still
resugar other templates used within those, though.
This patch does not actually implement any uses of this
functionality, those will be added in subsequent patches,
so expect no changes to existing tests.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D134604
Makes CheckTemplateArgumentList and the template deduction functions
produce a sugared converted argument list in addition to the canonical one.
This is mostly NFC except that we hook this up to a few diagnostics in
SemaOverload.
The infrastructure here will be used in subsequent patches
where we perform a finalized sugared substitution for entities
which we do not unique per specializations on canonical arguments,
and later on will be used for template specialization resugaring.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D133874
This reverts commit cecc9a92cfca71c1b6c2a35c5e302ab649496d11.
The problem ended up being how we were handling the lambda-context in
code generation: we were assuming any decl context here would be a
named-decl, but that isn't the case. Instead, we just replace it with
the concept's owning context.
Differential Revision: https://reviews.llvm.org/D136451
This reverts commit b876f6e2f28779211a829d7d4e841fe68885ae20.
Still getting build failures on PPC AIX that aren't obvious what is causing
them, so reverting while I try to figure this out.
This reverts commit b7c922607c5ba93db8b893d4ba461052af8317b5.
This seems to cause some problems with some modules related things,
which makes me think I should have updated the version-major in
ast-bit-codes? Going to revert to confirm this was a problem, then
change that and re-try a commit.
As that bug reports, the problem here is that the lambda's
'context-decl' was not set to the concept, and the lambda picked up
template arguments from the concept. SO, we failed to get the correct
template arguments in SemaTemplateInstantiate.
However, a Concept Specialization is NOT a decl, its an expression, so
we weren't able to put the concept in the decl tree like we needed.
This patch introduces a ConceptSpecializationDecl, which is the smallest
type possible to use for this purpose, containing only the template
arguments.
The net memory impliciation of this is turning a
trailing-objects into a pointer to a type with trailing-objects, so it
should be minor.
As future work, we may consider giving this type more responsibility, or
figuring out how to better merge duplicates, but as this is just a
template-argument collection at the moment, there isn't much value to
it.
Differential Revision: https://reviews.llvm.org/D136451
This is a change to how we represent type subsitution in the AST.
Instead of only storing the replaced type, we track the templated
entity we are substituting, plus an index.
We modify MLTAL to track the templated entity at each level.
Otherwise, it's much more expensive to go from the template parameter back
to the templated entity, and not possible to do in some cases, as when
we instantiate outer templates, parameters might still reference the
original entity.
This also allows us to very cheaply lookup the templated entity we saw in
the naming context and find the corresponding argument it was replaced
from, such as for implementing template specialization resugaring.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D131858
- store NestedNameSpecifier & Loc for the qualifiers
This information was entirely missing from the AST.
- expose the location information for qualifier/identifier/typedefs as typeloc
This allows many traversals/astmatchers etc to handle these generically along
with other references. The decl vs type split can help preserve typedef
sugar when https://github.com/llvm/llvm-project/issues/57659 is resolved.
- fix the SourceRange of UsingEnumDecl to include 'using'.
Fixes https://github.com/clangd/clangd/issues/1283
Differential Revision: https://reviews.llvm.org/D134303
