[Clang][concepts] Conditional explicit specifier is checked too early in constrained constructor

[JMazurkiewicz]

Repro (3rd version, 2nd version reproduced other possible bug; see edit history):

template<class X>
constexpr X failure() {
    return nullptr;
}

struct T {
    template<class X>
        requires false
    constexpr explicit(failure<X>()) T(X) { }

    T(int) { }
};

static T t(5);

Expected: correct compilation

Got:

<source>:3:12: error: cannot initialize return object of type 'int' with an rvalue of type 'std::nullptr_t'
    return nullptr;
           ^~~~~~~
<source>:9:24: note: in instantiation of function template specialization 'failure<int>' requested here
    constexpr explicit(failure<X>()) T(X) { }
                       ^
<source>:14:10: note: while substituting deduced template arguments into function template 'T' [with X = int]
static T t(5);
         ^

Compiler explorer: https://godbolt.org/z/sPsGh46Gs
Discovered in: microsoft/STL#3323

[llvmbot]

@llvm/issue-subscribers-c-20

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[CaseyCarter]

I believe the key wording here is [over.match.funcs.general]/8: "... If a constructor template or conversion function template has an explicit-specifier whose constant-expression is value-dependent ([temp.dep]), template argument deduction is performed first and then, if the context admits only candidates that are not explicit and the generated specialization is explicit ([dcl.fct.spec]), it will be removed from the candidate set. ..."

Also, I think the repro could be a bit cleaner (https://godbolt.org/z/sszb5z5ha):

template<class> constexpr bool always_false = false;

template<class T> concept False = always_false<T>;

template<class X>
constexpr bool do_not_instantiate() {
    static_assert(always_false<X>);
    return true;
}

struct T {
    template<False X>
    explicit(do_not_instantiate<X>()) T(X) { }

    T(int) { }
};

T t(5);

• requires false smells like IF-NDR, best to avoid it
• static is extraneous, as is constexpr on the constructor
• the expression in the explicit-specifier correctly has type bool after substitution.

[nitnelave]

Note that it makes clang-17 unable to compile a lot of code with the libstdc++ distributed with GCC 13. You can reproduce by trying to compile std::is_constructible<std::tuple<int>, std::tuple<>> (root cause is the same)

[shafik]

CC @erichkeane

[LYP951018]

i've been hacking on this weeks ago. Currently I partially instantiate the constructor decl (without instantiate the explicit specifier) and mutate the AST via setExplicitSpecifier after deferred instantiation of explicit speciifer during template argument deduction. Is that reansonable? I want to ensure the decl specialization have resolved explicit specifier... Could you please give me some advice on this? @erichkeane ;)

[erichkeane]

I think that seams reasonable. I believe there is a version of the exception specifier 'storage' that allows us to have uninstantiated exception specifiers in place, and I think we should be able to use that. It might 'just work' after that, since i think later lookups/uses of these check and instantiate that.

[LYP951018]

This issue is about explicit specifier but not exception specifier. Did I miss anything here?

[erichkeane]

This issue is about explicit specifier but not exception specifier. Did I miss anything here?

Woops, nope, I think I did. I don't have a good idea here unfortunately on how to give advise then, but what you said in your post at least seems promising.