[Clang] Remove unnecessary Decl transform & profiles for SizeOfPackExpr (#124533)

We used to always transform the pattern declaration for SizeOfPackExpr
to ensure the constraint expression's profile

[Clang] Remove unnecessary Decl transform & profiles for SizeOfPackExpr (#124533)

We used to always transform the pattern declaration for SizeOfPackExpr
to ensure the constraint expression's profile produced the desired
result. However, this approach failed to handle pack expansions when the
pack referred to function parameters. In such cases, the function
parameters were formerly expanded to 1 to avoid building Subst* nodes
(see e6974daa7). That workaround caused us to transform a pack without a
proper ArgumentPackSubstitutionIndex, leading to crashes when
transforming the pattern.

It turns out that profiling the pattern for partially substituted
SizeOfPackExprs is unnecessary because their transformed forms are also
profiled within the partial arguments.

Fixes https://github.com/llvm/llvm-project/issues/124161

show more ...

[Clang] SubstituteConstraintExpressionWithoutSatisfaction needs an unevaluated context (#123883)

It turns out that the substitution for expression comparing also needs
an unevaluated context, otherw

[Clang] SubstituteConstraintExpressionWithoutSatisfaction needs an unevaluated context (#123883)

It turns out that the substitution for expression comparing also needs
an unevaluated context, otherwise any reference to immediate functions
might not be properly handled.

As a fallout, this also guards the VLA transformation under unevaluated
context
with `InConditionallyConstantEvaluateContext` to avoid duplicate
diagnostics.

Fixes https://github.com/llvm/llvm-project/issues/123472

---------

Co-authored-by: cor3ntin <corentinjabot@gmail.com>

show more ...

[Clang] Remove the wrong assumption when rebuilding SizeOfPackExprs for constraint normalization (#115120)

In 463a4f150, we assumed that all the template argument packs are of
size 1 when normalizi

[Clang] Remove the wrong assumption when rebuilding SizeOfPackExprs for constraint normalization (#115120)

In 463a4f150, we assumed that all the template argument packs are of
size 1 when normalizing a constraint expression because I mistakenly
thought those packs were obtained from their injected template
parameters. This was wrong because we might be checking constraints when
instantiating a friend declaration within a class template
specialization, where the parent class template is specialized with
non-dependent template arguments.

In that sense, we shouldn't assume any pack size nor expand anything in
such a scenario. Moreover, there are no intermediate (substituted but
unexpanded) AST nodes for template template parameters, so we have to
special-case their transformations by looking into the instantiation
scope instead of extracting anything from template arguments.

Fixes #115098

show more ...

[Clang] Consider outer instantiation scopes for constraint normalization (#114749)

We need to compare constraint expressions when instantiating a friend
declaration that is lexically defined within

[Clang] Consider outer instantiation scopes for constraint normalization (#114749)

We need to compare constraint expressions when instantiating a friend
declaration that is lexically defined within a class template. Since the
evaluation is deferred, the expression might refer to untransformed
function parameters such that the substitution needs the mapping of
instantiation.

These mappings are maintained by the function declaration instantiation,
so we need to establish a "transparent" LocalInstantiationScope before
substituting into the constraint.

No release note as this fixes a regression in 19.

Fixes https://github.com/llvm/llvm-project/issues/114685

show more ...

[Clang] Emit a diagnostic note at the class declaration when the method definition does not match any declaration. (#110638)

Fixes #110558.

In this patch, we will emit a diagnostic note pointing

[Clang] Emit a diagnostic note at the class declaration when the method definition does not match any declaration. (#110638)

Fixes #110558.

In this patch, we will emit a diagnostic note pointing to the class
declaration when a method definition does not match any declaration.
This approach, similar to what GCC does, makes the diagnostic more
user-friendly.

---------

Co-authored-by: Vlad Serebrennikov <serebrennikov.vladislav@gmail.com>

show more ...

[Clang][Concepts] Normalize SizeOfPackExpr's pack declaration (#110238)

SizeOfPackExpr has a pointer to the referenced pack declaration, which
is left as-is during the transformation process.

Th

[Clang][Concepts] Normalize SizeOfPackExpr's pack declaration (#110238)

SizeOfPackExpr has a pointer to the referenced pack declaration, which
is left as-is during the transformation process.

The situation could be subtle when a friend class template declaration
comes into play. The declaration per se would be instantiated into its
parent declaration context, and consequently, the template parameter
list would have a depth adjustment; however, as we don't evaluate
constraints during instantiation, those constraints would still
reference the original template parameters, which is fine for constraint
evaluation because we have handled friend cases in the template argument
collection.

However, things are different when we want to profile the constraint
expression with dependent template arguments. The hash algorithm of
SizeOfPackExpr takes its pack declaration as a factor, which is the
original template parameter that might still have untransformed template
depths after the constraint normalization.

This patch transforms the pack declaration when normalizing constraint
expressions and pluses a fix in HandleFunctionTemplateDecl() where the
associated declaration is incorrect for nested specifiers.

Note that the fix in HandleFunctionTemplateDecl(), as well as the
handling logic for NestedNameSpecifier, would be removed once Krystian's
refactoring patch lands. But I still want to incorporate it in the patch
for the correction purpose, though it hasn't caused any problems so far
- I just tripped over that in getFullyPackExpandedSize() when I tried to
extract the transformed declarations from the TemplateArgument.

Fixes #93099

---------

Co-authored-by: Matheus Izvekov <mizvekov@gmail.com>

show more ...

[clang][NFC] Add regression tests for GH63782 (#109104)

Patch by Alejandro Alvarez Ayllon!

CPP-5380

[Clang][Concepts] Fix the constraint equivalence checking involving parameter packs (#102131)

We established an instantiation scope in order for constraint
equivalence checking to properly map the

[Clang][Concepts] Fix the constraint equivalence checking involving parameter packs (#102131)

We established an instantiation scope in order for constraint
equivalence checking to properly map the uninstantiated parameters.

That mechanism mapped even packs to themselves. Consequently, parameter
packs e.g. appearing in a function call, were not expanded. So they
would end up becoming `SubstTemplateTypeParmPackType`s that circularly
depend on the canonical declaration of the function template, which is
not yet determined, hence the spurious error.

No release note as I plan to backport it to 19.

Fixes https://github.com/llvm/llvm-project/issues/101735

---------

Co-authored-by: cor3ntin <corentinjabot@gmail.com>

show more ...

[concepts] Extract function template pack arguments from the current instantiation if possible (#80594)

Before the constraint substitution, we employ
`getTemplateInstantiationArgs`, which in turn a

[concepts] Extract function template pack arguments from the current instantiation if possible (#80594)

Before the constraint substitution, we employ
`getTemplateInstantiationArgs`, which in turn attempts to inspect
`TemplateArgument`s from the function template. For parameter packs from
their parent contexts, we used to extract the arguments from the
specialization type, in which could result in non-canonical argument
types e.g. `PackExpansionType`.

This may break the contract that, during a tree transformation, in
`TreeTransform::TryExpandParameterPacks`, the corresponding
`TemplateArgument`s for an `UnexpandedParameterPack` are expected to be
of `Pack` kinds if we're expanding template parameters.

Fixes https://github.com/llvm/llvm-project/issues/72557.

show more ...

[concepts] Push a CurContext before substituting into out-of-line constraints for comparison (#79985)

[concepts] Set up an instantiation scope for constraint expression comparison (#79698)

This is a follow-up for the comparison of constraints on out-of-line
function template definitions. We require

[concepts] Set up an instantiation scope for constraint expression comparison (#79698)

This is a follow-up for the comparison of constraints on out-of-line
function template definitions. We require the instantiation of a
ParmVarDecl while transforming the expression if that Decl gets
referenced by a DeclRefExpr. However, we're not actually performing the
class or function template instantiation at the time of such comparison.
Therefore, let's map these parameters to themselves so that they get
preserved after the substitution.

Fixes https://github.com/llvm/llvm-project/issues/74447.

show more ...

[Sema] When checking for constraint equivalence, do not calculate satisfaction (#74490)

... and only look at equivalence of substituted expressions, not results
of constraint satisfaction.
This is

[Sema] When checking for constraint equivalence, do not calculate satisfaction (#74490)

... and only look at equivalence of substituted expressions, not results
of constraint satisfaction.
This is required by the standard when matching redeclarations.

Fixes #74314.

There is already some existing machinery for that in
`TemplateInstantiator` and `Sema` exposed separate functions for
substituting expressions with intention to do that:
- `Sema::SubstExpr` should not evaluate constraints.
- `Sema::SubstConstraintExpr` should.

However, both functions used to be equivalent. Introduce a new function
that does not evaluate constraint and use it when matching declarations.

Also change implementation of `SubstConstraintExpr` to call `SubstExpr`
directly so it's obvious they behave in the same way and add a FIXME to
call out that we might need to revamp this approach in the future.

show more ...

Diagnose use of VLAs in C++ by default

Reapplication of 7339c0f782d5c70e0928f8991b0c05338a90c84c with a fix
for a crash involving arrays without a size expression.

Clang supports VLAs in C++ as an

Diagnose use of VLAs in C++ by default

Reapplication of 7339c0f782d5c70e0928f8991b0c05338a90c84c with a fix
for a crash involving arrays without a size expression.

Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they're expressed in C have been considered by WG21
and rejected, are easy to use accidentally to the surprise of users
(e.g., https://ddanilov.me/default-non-standard-features/), and they
have potential security implications beyond constant-size arrays
(https://wiki.sei.cmu.edu/confluence/display/c/ARR32-C.+Ensure+size+arguments+for+variable+length+arrays+are+in+a+valid+range).
C++ users should strongly consider using other functionality such as
std::vector instead.

This seems like sufficiently compelling evidence to warn users about
VLA use by default in C++ modes. This patch enables the -Wvla-extension
diagnostic group in C++ language modes by default, and adds the warning
group to -Wall in GNU++ language modes. The warning is still opt-in in
C language modes, where support for VLAs is somewhat less surprising to
users.

RFC: https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109
Fixes https://github.com/llvm/llvm-project/issues/62836
Differential Revision: https://reviews.llvm.org/D156565

show more ...

Revert "Diagnose use of VLAs in C++ by default"

This reverts commit 7339c0f782d5c70e0928f8991b0c05338a90c84c.

Breaks bots:
https://lab.llvm.org/buildbot/#/builders/139/builds/51875
https://lab.llvm

Revert "Diagnose use of VLAs in C++ by default"

This reverts commit 7339c0f782d5c70e0928f8991b0c05338a90c84c.

Breaks bots:
https://lab.llvm.org/buildbot/#/builders/139/builds/51875
https://lab.llvm.org/buildbot/#/builders/164/builds/45262

show more ...

Diagnose use of VLAs in C++ by default

Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they'r

Diagnose use of VLAs in C++ by default

Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they're expressed in C have been considered by WG21
and rejected, are easy to use accidentally to the surprise of users
(e.g., https://ddanilov.me/default-non-standard-features/), and they
have potential security implications beyond constant-size arrays
(https://wiki.sei.cmu.edu/confluence/display/c/ARR32-C.+Ensure+size+arguments+for+variable+length+arrays+are+in+a+valid+range).
C++ users should strongly consider using other functionality such as
std::vector instead.

This seems like sufficiently compelling evidence to warn users about
VLA use by default in C++ modes. This patch enables the -Wvla-extension
diagnostic group in C++ language modes by default, and adds the warning
group to -Wall in GNU++ language modes. The warning is still opt-in in
C language modes, where support for VLAs is somewhat less surprising to
users.

RFC: https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109
Fixes https://github.com/llvm/llvm-project/issues/62836
Differential Revision: https://reviews.llvm.org/D156565

show more ...

[CONCEPTS]Corrected comparison of constraints with out of line CTD (#69244)

Out of line class template declaration specializations aren't created at
the time they have their template arguments chec

[CONCEPTS]Corrected comparison of constraints with out of line CTD (#69244)

Out of line class template declaration specializations aren't created at
the time they have their template arguments checked, so we previously
weren't doing any amount of work to substitute the constraints before
comparison. This resulted in the out of line definition's difference in
'depth' causing the constraints to compare differently.

This patch corrects that. Additionally, it handles ClassTemplateDecl
when collecting template arguments.

Fixes: #61763

show more ...

Fix out of line Concept-comparisons of NestedNameSpecifiers (#65993)

As reported in GH65810, we don't properly collect ALL of the template
parameters in a nested name specifier, and were only doing

Fix out of line Concept-comparisons of NestedNameSpecifiers (#65993)

As reported in GH65810, we don't properly collect ALL of the template
parameters in a nested name specifier, and were only doing the 'inner
level'.

This patch makes sure we collect from all levels.

Fixes: #65810

show more ...

Fix comparison of constrained deduced return types in explicit
instantiations.

Fixes #62272.

Ensure comparison of constraints creates a code synth context

This is a regression from 6db007a0 that was reported in:
https://github.com/llvm/llvm-project/issues/62697

The assertion was because we

Ensure comparison of constraints creates a code synth context

This is a regression from 6db007a0 that was reported in:
https://github.com/llvm/llvm-project/issues/62697

The assertion was because we require a code synthesis context for the
instantiation of templates, and this reproducer causes a comparison that
doesn't have a parent-template causing one to exists.

This patch fixes it by creating a ConstraintNormalization context.

show more ...

[Clang][Sema] Fix comparison of constraint expressions

This diff switches the approach to comparison of constraint expressions
to the new one based on template args substitution.
It continues the ef

[Clang][Sema] Fix comparison of constraint expressions

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

show more ...

Revert "[Clang][Sema] Fix comparison of constraint expressions"

This reverts commit 3a540229341e3c8dc6d8ee61309eafaf943ea254.
A new regression is discovered and needs to be investigated.

[Clang][Sema] Fix comparison of constraint expressions

This diff switches the approach to comparison of constraint expressions
to the new one based on template args substitution.
It continues the ef

[Clang][Sema] Fix comparison of constraint expressions

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

show more ...

Revert "[Clang][Sema] Fix comparison of constraint expressions"

This reverts commit e3b1083e00e62f5d157d15cb8c63a1c3dfdf12e2.

This was reverted because it breaks a number of libstdc++ examples, AND

Revert "[Clang][Sema] Fix comparison of constraint expressions"

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.

show more ...

[Clang][Sema] Fix comparison of constraint expressions

This diff switches the approach to comparison of constraint expressions
to the new one based on template args substitution.
It continues the ef

[Clang][Sema] Fix comparison of constraint expressions

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

show more ...

Revert "[Clang][Sema] Fix comparison of constraint expressions"

This temporarily reverts commit
60bee9ff544541e83ffbd4be31923d0e8b644690.
The diff will be recommitted once the newly discovered
regre

Revert "[Clang][Sema] Fix comparison of constraint expressions"

This temporarily reverts commit
60bee9ff544541e83ffbd4be31923d0e8b644690.
The diff will be recommitted once the newly discovered
regressions are fixed.

show more ...