P3865R3 CTAD through a template template parameter: internal error when the deducing cast is inside an alias template

[stevensudit-corvid]

Issue Summary

The front end supports class template argument deduction through a type template template parameter (EDGcpfe/28857, with follow-up work in EDGcpfe/29001). One case looks like it is not covered yet: the deducing cast, C(0), is the decltype operand of an alias template, and the alias is named in a requires-expression. That stops the compilation with an internal error.

gcc and clang accept the code. I ran into it through std::ranges::to<std::vector>() with libstdc++ 16, whose implementation has this shape.

Reproducing Source Code

template<class T> struct vec { vec(T); };
template<template<class> class C> using ded = decltype(C(0));
template<template<class> class C> constexpr bool ok = requires { typename ded<C>; };
bool b = ok<vec>;

Command-line Options

cpfe --c++23 repro.cpp

Type of Issue

[Front End] I do not care but this code CRASHES the compiler.

Additional Details

The diagnostic, at 158320e (version 7.0):

"repro.cpp", line 3: internal error: assertion failed at: "exprutil.c", line
          16063 in generic_cast_operand

  template<template<class> class C> constexpr bool ok = requires { typename ded<C>; };
                                                                                     ^

1 catastrophic error detected in the compilation of "repro.cpp".
Compilation aborted.

--c++20 and --c++26 give the same result, and so do the GNU, Clang and Microsoft modes. With braces in the alias, decltype(C{0}), the assertion is at exprutil.c line 15962 in prep_generic_operand_full.

The same alias gives an ordinary error in two other places. Both files are valid C++17, and gcc and clang accept them, but --c++17 through --c++26 under cpfe reject them in every mode.

As a function template's return type:

template<class T> struct vec { vec(T); };
template<template<class> class C> using ded = decltype(C(0));
template<template<class> class C> ded<C> to();
auto f() { return to<vec>(); }

"ret.cpp", line 4: error: template instantiation resulted in unexpected
          function type of "ded<vec> ()" (aka "vec<int> ()") (the meaning of a
          name may have changed since the template declaration -- the type of
          the template is "ded<C> ()" (aka "decltype((<expression>)) ()"))

As a default template argument:

template<class T> struct vec { vec(T); };
template<template<class> class C> using ded = decltype(C(0));
template<template<class> class C, class = ded<C>> void f();
void g() { f<vec>(); }

"dflt.cpp", line 4: error: no instance of function template "f" matches the
          argument list
"dflt.cpp", line 3: note: candidate function template "f" failed deduction

These uses compile:

• The cast written without the alias, in each of the three places: requires { C(0); }, decltype(C(0)) to(); and class = decltype(C(0)).
• A class template with a member typedef in place of the alias: requires { typename ded<C>::type; }.
• The alias named directly, ded<vec> x(0);, or as a member type or a variable template's type.
• The same requires-expression in a concept.

What I saw in a linux-gcc-debug build, which may save you a step. For a placeholder that names a template template parameter, deduce_class_template_args asks bound_template_template_argument (templates.c:46128) for the template bound to the parameter's symbol. When the alias is substituted through copy_type_with_substitution and decltype_of_expr_with_substitution, the placeholder still names the alias's own parameter C, and that symbol's argument_template is C itself. The answer is therefore "still dependent" (overload.c:30971). scan_functional_notation_type_conversion then takes its dependent branch and calls generic_cast_operand (expr.c:31183), which asserts is_template_dependent_context(). The two error cases reach the same "still dependent" answer from substitute_template_arguments. The direct use, ded<vec> x(0);, scans the alias from its tokens in instantiate_template_alias, and there the parameter is bound to vec.

The libstdc++ 16 form is std::views::iota(0, 3) | std::ranges::to<std::vector>(). It hits the same assertion at line 9712 of <ranges>, on if constexpr (requires { typename _DeduceExpr1<_Cont, _Rg, _Args...>; }).

nvcc 13.3, which embeds EDG 6.8, compiles all three files, so this behavior is newer than 6.8. I have not bisected it.

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.