[Bug c++/105220] New: Incorrect concept evaluation when friend class is involved

[Bug c++/105220] New: Incorrect concept evaluation when friend class is involved

[martin.koch at bachmann dot info]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105220

            Bug ID: 105220
           Summary: Incorrect concept evaluation when friend class is
                    involved
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: martin.koch at bachmann dot info
  Target Milestone: ---

Assume we have a concept which checks whether a type implements a method foo:
template <typename T>
concept fooable = requires(const T &t) {
    t.foo();
};

And a class makes use of this concept:
template <typename T>
requires fooable<T>
struct A<T> { ... }

And some other class declares A as a friend:
class B {
   private:
    friend struct A<B>;
    void foo() const {
        std::cout << "foo called" << std::endl;
    }
};

In this case B is not considered "fooable" in the template specialization of
A<B>.
With clang it works fine. See: https://godbolt.org/z/8qWrPfd4b

[Bug c++/105220] Incorrect concept evaluation when friend class is involved

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105220

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2022-04-11
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org
                 CC|                            |ppalka at gcc dot gnu.org
     Ever confirmed|0                           |1
      Known to fail|                            |10.3.0, 11.2.0, 12.0

--- Comment #1 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Confirmed, reduced rejects-valid testcase:

template<class T>
concept fooable = requires(T t) { t.foo(); };

template<class>
struct A;        // #1

template<fooable T>
struct A<T> { }; // #2

struct B {
private:
  friend struct A<B>;
  void foo();
};

A<B> a; // should use #2


When determining whether to use #1 or #2 for A<B>, we check #2's constraints in
the context of the template rather than the context of the specialization, so
the friend declaration doesn't apply.  Thus one workaround is to declare a
template friend instead:

  template<class> friend struct A;

[Bug c++/105220] [CWG2589] concept evaluation and friendship

[jason at gcc dot gnu.org]

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.