public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/105220] New: Incorrect concept evaluation when friend class is involved
@ 2022-04-11 13:56 martin.koch at bachmann dot info
2022-04-11 15:17 ` [Bug c++/105220] " ppalka at gcc dot gnu.org
2023-12-10 20:17 ` [Bug c++/105220] [CWG2589] concept evaluation and friendship jason at gcc dot gnu.org
0 siblings, 2 replies; 3+ messages in thread
From: martin.koch at bachmann dot info @ 2022-04-11 13:56 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug c++/105220] Incorrect concept evaluation when friend class is involved
2022-04-11 13:56 [Bug c++/105220] New: Incorrect concept evaluation when friend class is involved martin.koch at bachmann dot info
@ 2022-04-11 15:17 ` ppalka at gcc dot gnu.org
2023-12-10 20:17 ` [Bug c++/105220] [CWG2589] concept evaluation and friendship jason at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: ppalka at gcc dot gnu.org @ 2022-04-11 15:17 UTC (permalink / raw)
To: gcc-bugs
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;
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug c++/105220] [CWG2589] concept evaluation and friendship
2022-04-11 13:56 [Bug c++/105220] New: Incorrect concept evaluation when friend class is involved martin.koch at bachmann dot info
2022-04-11 15:17 ` [Bug c++/105220] " ppalka at gcc dot gnu.org
@ 2023-12-10 20:17 ` jason at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: jason at gcc dot gnu.org @ 2023-12-10 20:17 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-12-10 20:17 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-11 13:56 [Bug c++/105220] New: Incorrect concept evaluation when friend class is involved martin.koch at bachmann dot info
2022-04-11 15:17 ` [Bug c++/105220] " ppalka at gcc dot gnu.org
2023-12-10 20:17 ` [Bug c++/105220] [CWG2589] concept evaluation and friendship jason at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).