Rejects-valid with variadic alias template in variadic class template

[efriedma-quic]

Bugzilla Link	16668
Version	unspecified
OS	All
Attachments	Patch for discussion
CC	@DougGregor,@zygoloid

Extended Description

Testcase:

template<int ...Args1> struct A {
template<int ...Args2> using B = A<(Args1+Args2)...>;
};
template<int ...Args> using X = A<1,2,3>::B<Args...>;

Currently prints:
:2:53: error: pack expansion contains parameter pack 'Args2' that has a different length (3 vs. 1) from outer parameter packs
template<int ...Args2> using B = A<(Args1+Args2)...>;
~~~~~ ^
:4:43: note: in instantiation of template type alias 'B' requested here
template<int ...Args> using X = A<1,2,3>::B<Args...>;
^
1 error generated.

I don't see any obvious reason why this wouldn't be allowed by the standard.

[zygoloid]

My current line of thinking is that clang is expanding the parameter pack
too early; attached patch delays the expansion. Not a complete patch, but
this illustrates what I'm thinking.

I came up with an essentially identical approach. The test added for #17020 seems to fail with such a patch, due to an assertion failure in template argument deduction. Extended test case triggering the same assertion failure:

--- test/SemaCXX/alias-template.cpp (revision 186726)
+++ test/SemaCXX/alias-template.cpp (working copy)
@@ -170,3 +170,34 @@
fail1 f1; // expected-note {{here}}
fail2 f2; // expected-note {{here}}
}
+
+namespace #17042 {

• template<int, typename> struct P {};
• template<int ...A> struct S {
• template<int ...B> using sum = S<A + B ...>; // expected-error {{different length (3 vs. 4)}}
• template<typename ...Ts> void f(P<A, Ts> ...);
• template<typename ...Ts> using Fn = void(S::*)(P<A, Ts>...);
• template<typename ...Ts> void g(Fn<Ts...>);
• };
• template<int ...C> using X = S<1, 2, 3>::sum<4, C ...>; // expected-note {{here}}
• using Y = X<5, 6>;
• using Y = S<5, 7, 9>;
• using Z = X<5, 6, 7>; // expected-note {{here}}
• void g() {
• P<0, int> p0;
• P<1, char> p1;
• P<2, double> p2;
• using S = S<0, 1, 2>;
• S s;
• s.f(p0, p1, p2);
• s.g(&S::f<int, char, double>);
• s.g<int, char, double>(&S::f);
• }
  +}

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[Endilll]

Nothing has changed as of Clang 16: https://godbolt.org/z/86YzhKjb6

[vient]

Since #61415 seems to be caused by this issue, I'll note that this is affecting c++23 builds with libstdc++-13.

Example

docker run -it --rm ubuntu:mantic bash -c "
export DEBIAN_FRONTEND=noninteractive TZ=Etc/UTC
apt update
apt install -y gcc-13 clang-17
echo '
  #include <map>
  #include <tuple>
  void f() {
    std::map<std::tuple<int, int>, int>{}[std::make_tuple(0, 0)];
  }
' > test.cpp
clang++-17 -std=c++23 test.cpp"

https://godbolt.org/z/obGY1a8rr

[vient]

My previous example seems to be fixed in trunk: https://godbolt.org/z/eMfYsEbo1
But the original one here is not: https://godbolt.org/z/TPdhK7rGv