Spurious "unexpected function type": the enclosing class's pack reverts to its first element in a member function template declaration

[stevensudit-corvid]

Issue Summary

In the declaration of a member function template of a variadic class template, a pack expansion over the class's pack can use the first pack element in every position. Instantiating the member then fails with "template instantiation resulted in unexpected function type".

gcc and clang accept the code. I ran into it in a helper that removes duplicate types from a std::tuple, where the pattern calls first_index_of<Ss, Ss...>() before it names std::tuple<Ss>.

Reproducing Source Code

template<class...> struct tup {};
template<class... Ss> struct d {
  template<class U> static tup<tup<tup<>, Ss>...> keep(U);
};
decltype(d<int, char>::keep(0)) x;

Command-line Options

cpfe --c++23 repro.cpp

Type of Issue

[Front End] This code SHOULD compile with these options.

Additional Details

The diagnostic, at 158320e (version 7.0):

"repro.cpp", line 5: error: template instantiation resulted in unexpected
          function type of "tup<tup<tup<>, int>, tup<tup<>, char>> (int)" (the
          meaning of a name may have changed since the template declaration --
          the type of the template is "tup<tup<tup<>, int>, tup<tup<>, int>>
          (U)")
  decltype(d<int, char>::keep(0)) x;
                                ^
          detected during instantiation of "d<Ss...>::keep [with Ss=<int,
                    char>]" based on template argument <int> at line 5

The second type in the message is the declared type of keep inside d<int, char>. It has int where char belongs.

Every level from --c++11 to --c++26 gives the same error, and so do the GNU, Clang and Microsoft modes.

The trigger is a construct with its own potential pack-expansion context that comes before the use of Ss in the pattern. I found three, all with the same result:

• An empty template argument list, as above. A defaulted one behaves the same: tup<tup<one<>, Ss>...> with template<class = int> struct one {};.
• A nested expansion of the same pack: tup<tup<tup<Ss...>, Ss>...>. Here the declared type is tup<tup<tup<int, char>, int>, tup<tup<int, char>, int>>.
• A parenthesized expression, at --c++17 and later: tup<q<(1), Ss>...> with template<int, class> struct q {};.

Any one of these changes makes the example compile:

• The empty list comes after the pack: tup<tup<Ss, tup<>>...>.
• The list is not empty: tup<tup<tup<int>, Ss>...>.
• tup<> is named through an alias declared outside the class.
• keep is a non-template member function.
• keep is a member alias template or a member class template with the same pattern.
• keep is a free function template that expands its own pack.

d<int, int> also compiles, since the two types then coincide.

When the pattern is in a function parameter pack, the same wrong type shows up as a failed call:

template<class...> struct tup {};
template<class... Ss> struct d {
  template<class U> static void keep(U, tup<tup<>, Ss>...);
};
void f() { d<int, char>::keep(0, tup<tup<>, int>{}, tup<tup<>, char>{}); }

"param.cpp", line 5: error: no instance of function template "d<Ss...>::keep
          [with Ss=<int, char>]" matches the argument list
            argument types are: (int, tup<tup<>, int>, tup<tup<>, char>)

What I saw in a linux-gcc-debug build: when scan_template_argument_list reaches the empty list, it calls abandon_potential_pack_expansion_context (lexical.c:21660), which pops the pack-expansion stack and reaches restore_enclosing_pack_values (scope_stk.c:2276). That routine rebinds the instantiation scope's template parameters to the scope's argument list (line 2296), which points Ss back at int. It then calls update_parameter_pack_symbol_values only if the entry now on top of the stack has an instantiation_descr (line 2307). At that point the top entry has none and the entry below it has one, so Ss stays on the first element for the rest of the pattern. The nested expansion gets there through advance_to_next_pack_element, with the stack in the same state. I have not traced why a non-template member function in the same position is unaffected.

Two earlier entries in Changes are in the same area: EDGcpfe/13643 (5/17/13, "Variadic template issue with member function templates and enclosing packs") and EDGcpfe/17028 (4/14/16, "Incorrect expansion of nested pack expansion"). The example from 13643 compiles.

nvcc 13.3, which embeds EDG 6.8, rejects the five-line file with the same message, so this is not new in 7.0.

Reproducing (Standard) Configuration(s)

linux-gcc-release

Reproducing (Non-standard) Configuration

No response

I acknowledge that:

• I have checked open issues and existing discussions before filing this report.
• The reproducing source code that I have provided does not depend on headers that I have not included with my submission.
• I have reduced the reproducing source code to the best of my ability.
• I have selected at least one standard configuration or uploaded a non-standard configuration dump.
• I understand code shared via this form is NOT confidential.
• I have permission to share the reproducing source code and grant permission for the project to use the source code (or derivatives of the source code) to create tests.
• I agree that any tests created using the reproducing source code (or deriatives of it) will be licensed under project license unless I included a LICENSE.txt file in my .zip or .tar.gz upload. If I included a LICENSE.txt file, any tests created using the reproducing source code will be governed by the terms of the license I provided instead.