Bogus error when using `__reference_converts_from_temporary` in default template argument

[aaronpuchert]

We ran into this with an std::function (libstdc++ 13) returning an object with protected copy constructor. It boils down to this:

class X {
protected:
    X(const X&);
};

static_assert(!__reference_converts_from_temporary(X, X));

template<typename A, typename B,
         bool Dangle = __reference_converts_from_temporary(A, B)>
static void test();

using Result = decltype(test<X, X>());

produces:

bug.cpp:9:24: error: calling a protected constructor of class 'X'
    9 |          bool Dangle = __reference_converts_from_temporary(A, B)>
      |                        ^

Replacing either A or B by X doesn't make the error go away. Interestingly, if we define test, for example with an empty body, and do a full instantiation, then the error appears if the instantiation is implicit, but not if it's explicit:

template<typename A, typename B,
         bool Dangle = __reference_converts_from_temporary(A, B)>
static void test() {} // <-- Added an empty body.

template void test<X, X>(); // No error.

void f() {
    test<X, X>(); // Error.
}

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Aaron Puchert (aaronpuchert)

We ran into this with an `std::function` (libstdc++ 13) returning an object with protected copy constructor. It boils down to this:

class X {
protected:
    X(const X&);
};

static_assert(!__reference_converts_from_temporary(X, X));

template<typename A, typename B,
         bool Dangle = __reference_converts_from_temporary(A, B)>
static void test();

using Result = decltype(test<X, X>());

produces:

bug.cpp:9:24: error: calling a protected constructor of class 'X'
    9 |          bool Dangle = __reference_converts_from_temporary(A, B)>
      |                        ^

Replacing either A or B by X doesn't make the error go away. Interestingly, if we define test, for example with an empty body, and do a full instantiation, then the error appears if the instantiation is implicit, but not if it's explicit:

template<typename A, typename B,
         bool Dangle = __reference_converts_from_temporary(A, B)>
static void test() {} // <-- Added an empty body.

template void test<X, X>(); // No error.

void f() {
    test<X, X>(); // Error.
}

[aaronpuchert]

@cor3ntin, if you want to have a look.

[aaronpuchert]

The issue seems to affect other type traits as well:

static_assert(!__is_convertible(X, X));

template<typename A, typename B,
         bool = __is_convertible(A, B)> // error: calling a protected constructor of class 'X'
static void test_conv();

using ResultConv = decltype(test_conv<X, X>());

and this:

class Y {
protected:
  Y(const X&);
};

template<typename A, typename B> struct BaseTemp {};
template<typename T> struct HasTypeMember {};

__builtin_common_type<BaseTemp, HasTypeMember, void, X, Y> f() {
  return; // Checks that we select `void`.
}

template<typename A, typename B,
         typename Res = __builtin_common_type<BaseTemp, HasTypeMember, void, A, B>>
static Res test_common_type();

decltype(test_common_type<X, Y>()) g() { return; }

Also here:

error: calling a protected constructor of class 'Y'
         typename Res = __builtin_common_type<BaseTemp, HasTypeMember, void, A, B>>
                        ^

For all these type traits, we use an SFINAETrap with AccessCheckingSFINAE = true to silence errors. The problem: errors might still be added to SuppressedDiagnostics in the TemplateDeductionInfo returned by isSFINAEContext (see Sema::EmitDiagnostic). When the overload candidate has been selected, those errors are emitted.

Why does this not happen outside of a template context or in an explicit instantiation? Both are not SFINAE contexts, and in the SFINAETrap constructor we have this:

      if (!SemaRef.isSFINAEContext())
        SemaRef.InNonInstantiationSFINAEContext = true;

So we already set the flag in non-SFINAE contexts. Setting this flag makes isSFINAEContext return a context that makes EmitDiagnostic swallow all errors. So I think we have to set InNonInstantiationSFINAEContext to true even in SFINAE contexts, when we're trapping for these builtins.

It seems that actually all places with AccessCheckingSFINAE = true want this behavior, so I think we simply have to change the if condition to !SemaRef.isSFINAEContext() || AccessCheckingSFINAE. Currently this looks good, and we still have nested instantations emitting errors as they should.