Unexpected behavior in deduction of nested templates with template template parameters (inconsistent with GCC, MSVC)

[13steinj]

I don't have enough practice with standard-ese to express myself any better than that, unfortunately. Define EVEN_WORSE or ALTERNATIVE_EVEN_WORSE for a different, but seemingly related, inconsistency. Define FIXED to fix the original issue, and "fix" the "even worse" inconsistencies (successful compile, unexpectedly).

I'm happy to provide the motivating example, it's just larger. A whole load of transitional layers from one set of types to another.

Reduced Example

template<typename>
struct Wrapper;

template<template<typename> typename, typename T>
using ComposedWrapper = Wrapper<T>;

template<typename...>
struct mp_list;

template<typename>
struct converter_impl;

template<typename T>
using converter = converter_impl<T>::type;

template<
#if !defined(EVEN_WORSE)
    template<typename> typename Wrapper,
#endif
    typename T
>
struct converter_impl<mp_list<Wrapper<T>>> {
    using type = void;
};

template<typename T>
struct converter_impl<ComposedWrapper<Wrapper, T>> {
    using type = converter<T>;
};

#if defined(__clang__) && defined(FIXED)

template<typename T>
struct converter_impl<ComposedWrapper<Wrapper, mp_list<T>>> {
    using type = int;
};

#endif

template<typename>
concept valid = true;

static_assert(valid<converter<ComposedWrapper<Wrapper,
#if !defined(ALTERNATIVE_EVEN_WORSE)
    mp_list<
#endif
        mp_list<int>
#if !defined(ALTERNATIVE_EVEN_WORSE)
    >
#endif
>>>);

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: None (13steinj)

I don't have enough practice with standard-ese to express myself any better than that, unfortunately. Define `EVEN_WORSE` or `ALTERNATIVE_EVEN_WORSE` for a different, but seemingly related, inconsistency. Define `FIXED` to fix the original issue, and "fix" the "even worse" inconsistencies (successful compile, unexpectedly).

I'm happy to provide the motivating example, it's just larger. A whole load of transitional layers from one set of types to another.

<details>
<summary><a href="https://gcc.godbolt.org/z/Whqfnjv49"&gt;Reduced Example</href></summary>

template<typename>
struct Wrapper;

template<template<typename> typename, typename T>
using ComposedWrapper = Wrapper<T>;

template<typename...>
struct mp_list;

template<typename>
struct converter_impl;

template<typename T>
using converter = converter_impl<T>::type;

template<
#if !defined(EVEN_WORSE)
    template<typename> typename Wrapper,
#endif
    typename T
>
struct converter_impl<mp_list<Wrapper<T>>> {
    using type = void;
};

template<typename T>
struct converter_impl<ComposedWrapper<Wrapper, T>> {
    using type = converter<T>;
};

#if defined(__clang__) && defined(FIXED)

template<typename T>
struct converter_impl<ComposedWrapper<Wrapper, mp_list<T>>> {
    using type = int;
};

#endif

template<typename>
concept valid = true;

static_assert(valid<converter<ComposedWrapper<Wrapper,
#if !defined(ALTERNATIVE_EVEN_WORSE)
    mp_list<
#endif
        mp_list<int>
#if !defined(ALTERNATIVE_EVEN_WORSE)
    >
#endif
>>>);

</details>

[13steinj]

This might be a variation of #65843

[shafik]

I believe this is IFNDR, it depends on how aggressively the compiler instantiates and I believe is allowed to be more aggressive here.

Also see: #59966 (comment)

CC @erichkeane @cor3ntin

[13steinj]

I'm a bit confused in that the issue appears to be related to incomplete types. Yes, I'm using some incomplete types here, but this is just the reduced example. The larger example the types used in converter were all boost::mpll or boost::mp11 types that were not incomplete. Completing the incomplete types in the example does not resolve the issue.