Like during satisfaction, we need to check access immediately during substitution of a requires-expr since the outcome of an access check can determine the value of the requires-expr. And otherwise, in contexts where access checking is deferred (such as during substitution into a base-clause), a failed access check may leak out from the requires-expr into a non-SFINAE context and cause a hard error (as in the testcase below).
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? PR c++/107179 gcc/cp/ChangeLog: * constraint.cc (tsubst_requires_expr): Make sure we're not deferring access checks. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-requires31.C: New test. --- gcc/cp/constraint.cc | 3 +++ gcc/testsuite/g++.dg/cpp2a/concepts-requires31.C | 13 +++++++++++++ 2 files changed, 16 insertions(+) create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-requires31.C diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc index 5e6a3bcf059..f6ef078171a 100644 --- a/gcc/cp/constraint.cc +++ b/gcc/cp/constraint.cc @@ -2252,6 +2252,9 @@ tsubst_requires_expr (tree t, tree args, sat_info info) { local_specialization_stack stack (lss_copy); + /* We need to check access during the substitution. */ + deferring_access_check_sentinel acs (dk_no_deferred); + /* A requires-expression is an unevaluated context. */ cp_unevaluated u; diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-requires31.C b/gcc/testsuite/g++.dg/cpp2a/concepts-requires31.C new file mode 100644 index 00000000000..9b7e2a34889 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp2a/concepts-requires31.C @@ -0,0 +1,13 @@ +// PR c++/107179 +// { dg-do compile { target c++20 } } + +template<bool B> struct bool_constant { static constexpr bool value = B; }; + +template<typename T> + struct is_implicitly_default_constructible + : bool_constant<requires { T(); }> + { }; + +struct X { private: X(); }; + +static_assert( !is_implicitly_default_constructible<X>::value ); -- 2.38.1.381.gc03801e19c