https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105220
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at gcc dot gnu.org
Summary|Incorrect concept |[CWG2589] concept
|evaluation when friend |evaluation and friendship
|class is involved |
--- Comment #2 from Jason Merrill <jason at gcc dot gnu.org> ---
Relatedly, https://cplusplus.github.io/CWG/issues/2589.html says that clang and
gcc are wrong to consider friendship when checking access in an expression from
the definition of fooable, which is not in the scope of A<T>.
In my testcase from that issue (https://godbolt.org/z/aEvrjPGns):
template<class T> concept ctible = requires { T(); };
class A {
template <class T> friend struct B;
A();
};
template <class T> struct B;
template <ctible T> struct B<T> { T t; };
B<A> b; // #1
template <class T> struct C { };
template <ctible T> struct C<T> { T t; };
C<A> c; // #2
Currently clang and gcc both accept #1 and reject #2, because we cache the
value of ctible<A> and assume that we can reuse it in another context. But
that's broken, since the value was affected by its context; in the context of
C, A is not ctible. Either we need to (as proposed) calculate access in the
context of ctible rather than B and reject #1, or we need to not cache
satisfaction values that depend on access of private/protected members, and
accept both #1 and #2.
EDG and MSVC follow the proposed resolution of 2589.
