[Clang] Don't assume unexpanded PackExpansions' size when expanding packs (#120380)

CheckParameterPacksForExpansion() previously assumed that template
arguments don't include PackExpansion types whe

[Clang] Don't assume unexpanded PackExpansions' size when expanding packs (#120380)

CheckParameterPacksForExpansion() previously assumed that template
arguments don't include PackExpansion types when attempting another pack
expansion (i.e. when NumExpansions is present). However, this assumption
doesn't hold for type aliases, whose substitution might involve
unexpanded packs. This can lead to incorrect diagnostics during
substitution because the pack size is not yet determined.

To address this, this patch calculates the minimum pack size (ignoring
unexpanded PackExpansionTypes) and compares it to the previously
expanded size. If the minimum pack size is smaller, then there's still a
chance for future substitution to expand it to a correct size, so we
don't diagnose it too eagerly.

Fixes #61415
Fixes #32252
Fixes #17042

show more ...

[clang] Do not substitute parameter pack while retaining the pack expansion (#108197)

(In reference to https://github.com/llvm/llvm-project/pull/108197/commits/5901d82ea0543074853b963f7dc9106a6fe3bc

[clang] Do not substitute parameter pack while retaining the pack expansion (#108197)

(In reference to https://github.com/llvm/llvm-project/pull/108197/commits/5901d82ea0543074853b963f7dc9106a6fe3bcee)
Consider when `Input[I]` is a `VarDecl` with parameter pack. We would
have already expanded the pack before the code change in the loop`for
(unsigned I = 0; I != *NumExpansions; ++I) {`.

Now in `if (RetainExpansion) {`, without this change, we continue to
substitute the pack in the pattern even when we do not have meaningful
`ArgumentPackSubstitutionIndex` set.

This leads to use of an invalid pack substitution index in
`TemplateInstantiator::TransformFunctionParmPackRefExpr` in
`TransformedDecl = (*Pack)[getSema().ArgumentPackSubstitutionIndex];`

This change sets `ArgumentPackSubstitutionIndex` to `-1` while retaining
expansion to instruct `TransformFunctionParmPackRefExpr` to build
`FunctionParmPackExpr` instead of substituting the param pack.

---

There are other instances of `RetainExpansion` and IIUC, they should
also unset the `ArgumentPackSubstitutionIndex`. It would be great if
someone can verify my understanding. If this is correct then we could
instead have a `ArgumentPackSubstitutionIndexRAII` as part of
`ForgetPartiallySubstitutedPackRAII`.

EDIT: I have moved this to `ForgetPartiallySubstitutedPackRAII`.

Fixes https://github.com/llvm/llvm-project/issues/63819
Fixes https://github.com/llvm/llvm-project/issues/107560

show more ...

Revert two patches to fix GH58452 regression

GH58452 is a regression in the 16.0 release branch caused by both:
b8a1b698afb2fc84819c7596090aabf4d826b436 and
3a0309c53674be56b5cfce038d78a0c2c6e2a98c

Revert two patches to fix GH58452 regression

GH58452 is a regression in the 16.0 release branch caused by both:
b8a1b698afb2fc84819c7596090aabf4d826b436 and
3a0309c53674be56b5cfce038d78a0c2c6e2a98c

This patch reverts both of those to make the 'valid' code stop
diagnosing
at the expense of crashes on invalid + unclear diagnostics.

This patch also adds the tests from GH58452 to prevent any
re-application from breaking this again.

Revert "[clang] Improve diagnostics for expansion length mismatch"
This reverts commit 3a0309c53674be56b5cfce038d78a0c2c6e2a98c.
Revert "[clang] fix missing initialization of original number of expansions"
This reverts commit b8a1b698afb2fc84819c7596090aabf4d826b436.

Differential Revision: https://reviews.llvm.org/D145605

show more ...

[clang] Improve diagnostics for expansion length mismatch

When checking parameter packs for expansion, instead of basing the diagnostic for
length mismatch for outer parameters only on the known num

[clang] Improve diagnostics for expansion length mismatch

When checking parameter packs for expansion, instead of basing the diagnostic for
length mismatch for outer parameters only on the known number of expansions,
we should also analyze SubstTemplateTypeParmPackType and SubstNonTypeTemplateParmPackExpr
for unexpanded packs, so we can emit a diagnostic pointing to a concrete
outer parameter.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Differential Revision: https://reviews.llvm.org/D128095

show more ...

Recommit: Compress formatting of array type names (int [4] -> int[4])

Based on post-commit review discussion on
2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith.

Other uses of forcing Ha

Recommit: Compress formatting of array type names (int [4] -> int[4])

Based on post-commit review discussion on
2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith.

Other uses of forcing HasEmptyPlaceHolder to false seem OK to me -
they're all around pointer/reference types where the pointer/reference
token will appear at the rightmost side of the left side of the type
name, so they make nested types (eg: the "int" in "int *") behave as
though there is a non-empty placeholder (because the "*" is essentially
the placeholder as far as the "int" is concerned).

This was originally committed in 277623f4d5a672d707390e2c3eaf30a9eb4b075c

Reverted in f9ad1d1c775a8e264bebc15d75e0c6e5c20eefc7 due to breakages
outside of clang - lldb seems to have some strange/strong dependence on
"char [N]" versus "char[N]" when printing strings (not due to that name
appearing in DWARF, but probably due to using clang to stringify type
names) that'll need to be addressed, plus a few other odds and ends in
other subprojects (clang-tools-extra, compiler-rt, etc).

show more ...

Revert "Compress formatting of array type names (int [4] -> int[4])"

Looks like lldb has some issues with this - somehow it causes lldb to
treat a "char[N]" type as an array of chars (prints them ou

Revert "Compress formatting of array type names (int [4] -> int[4])"

Looks like lldb has some issues with this - somehow it causes lldb to
treat a "char[N]" type as an array of chars (prints them out
individually) but a "char [N]" is printed as a string. (even though the
DWARF doesn't have this string in it - it's something to do with the
string lldb generates for itself using clang)

This reverts commit 277623f4d5a672d707390e2c3eaf30a9eb4b075c.

show more ...

Compress formatting of array type names (int [4] -> int[4])

Based on post-commit review discussion on
2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith.

Other uses of forcing HasEmptyPlac

Compress formatting of array type names (int [4] -> int[4])

Based on post-commit review discussion on
2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith.

Other uses of forcing HasEmptyPlaceHolder to false seem OK to me -
they're all around pointer/reference types where the pointer/reference
token will appear at the rightmost side of the left side of the type
name, so they make nested types (eg: the "int" in "int *") behave as
though there is a non-empty placeholder (because the "*" is essentially
the placeholder as far as the "int" is concerned).

show more ...

Always deduce the lengths of contained parameter packs when deducing a
pack expansion.

Previously, if all parameter / argument pairs for a pack expansion
deduction were non-deduced contexts, we woul

Always deduce the lengths of contained parameter packs when deducing a
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.

show more ...

Remove an assert in template pack deduction during nested instantiation.

llvm-svn: 356231

Fix failing testcase to actually be valid.

llvm-svn: 337483

Fix template argument deduction when a parameter pack has a value
provided by an outer template.

We made the incorrect assumption in various places that the only way we
can have any arguments alread

Fix template argument deduction when a parameter pack has a value
provided by an outer template.

We made the incorrect assumption in various places that the only way we
can have any arguments already provided for a pack during template
argument deduction was from a partially-specified pack. That's not true;
we can also have arguments from an enclosing already-instantiated
template, and that can even result in the function template's own pack
parameters having a fixed length and not being packs for the purposes of
template argument deduction.

llvm-svn: 337481

show more ...

PR14615: add (passing) tests for this already-fixed bug

llvm-svn: 213709

Retain an expression pack expansion when the parameter pack expansion code asks
us to.

llvm-svn: 210355

PR14841: If partial substitution of explicitly-specified template arguments
results in a template having too many arguments, but all the trailing arguments
are packs, that's OK if we have a partial p

PR14841: If partial substitution of explicitly-specified template arguments
results in a template having too many arguments, but all the trailing arguments
are packs, that's OK if we have a partial pack substitution: the trailing pack
expansions may end up empty.

llvm-svn: 210350

show more ...

PR19878: If a pack expansion appears within another pack expansion, correctly
deduce any packs that are expanded by both expansions.

llvm-svn: 209786