public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jason Merrill <jason@redhat.com>
To: gcc-patches@gcc.gnu.org
Subject: [pushed] c++: hidden friend access [DR1699]
Date: Sun, 15 May 2022 12:44:51 -0400	[thread overview]
Message-ID: <20220515164451.3971995-1-jason@redhat.com> (raw)

It has come up several times that Clang considers hidden friends of a class
to be sufficiently memberly to be covered by a friend declaration naming the
class.  This is somewhat unclear in the standard: [class.friend] says
"Declaring a class to be a friend implies that private and protected members
of the class granting friendship can be named in the base-specifiers and
member declarations of the befriended class."

A hidden friend is a syntactic member-declaration, but is it a "member
declaration"?  CWG was ambivalent, and referred the question to EWG as a
design choice.  But recently Patrick mentioned that the current G++ choice
not to treat it as a "member declaration" was making his library work
significantly more cumbersome, so let's go ahead and vote the other way.

This means that the testcases for 100502 and 58993 are now accepted.

Tested x86_64-pc-linux-gnu, applying to trunk.

	DR1699
	PR c++/100502
	PR c++/58993

gcc/cp/ChangeLog:

	* friend.cc (is_friend): Hidden friends count as members.
	* search.cc (friend_accessible_p): Likewise.

gcc/testsuite/ChangeLog:

	* g++.dg/template/access37.C: Now OK.
	* g++.dg/template/friend69.C: Now OK.
	* g++.dg/lookup/friend23.C: New test.
---
 gcc/cp/friend.cc                         |  2 ++
 gcc/cp/search.cc                         |  7 ++-----
 gcc/testsuite/g++.dg/lookup/friend23.C   | 17 +++++++++++++++++
 gcc/testsuite/g++.dg/template/access37.C |  8 ++++----
 gcc/testsuite/g++.dg/template/friend69.C |  4 ++--
 5 files changed, 27 insertions(+), 11 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/lookup/friend23.C

diff --git a/gcc/cp/friend.cc b/gcc/cp/friend.cc
index 124ed4f3962..bf37dadeb62 100644
--- a/gcc/cp/friend.cc
+++ b/gcc/cp/friend.cc
@@ -131,6 +131,8 @@ is_friend (tree type, tree supplicant)
     {
       if (DECL_FUNCTION_MEMBER_P (supplicant))
 	context = DECL_CONTEXT (supplicant);
+      else if (tree fc = DECL_FRIEND_CONTEXT (supplicant))
+	context = fc;
       else
 	context = NULL_TREE;
     }
diff --git a/gcc/cp/search.cc b/gcc/cp/search.cc
index b86b3a24080..10863a40b11 100644
--- a/gcc/cp/search.cc
+++ b/gcc/cp/search.cc
@@ -734,12 +734,9 @@ friend_accessible_p (tree scope, tree decl, tree type, tree otype)
 	  && friend_accessible_p (DECL_CONTEXT (scope), decl, type, otype))
 	return 1;
       /* Perhaps SCOPE is a friend function defined inside a class from which
-	 DECL is accessible.  Checking this is necessary only when the class
-	 is dependent, for otherwise add_friend will already have added the
-	 class to SCOPE's DECL_BEFRIENDING_CLASSES.  */
+	 DECL is accessible.  */
       if (tree fctx = DECL_FRIEND_CONTEXT (scope))
-	if (dependent_type_p (fctx)
-	    && protected_accessible_p (decl, fctx, type, otype))
+	if (friend_accessible_p (fctx, decl, type, otype))
 	  return 1;
     }
 
diff --git a/gcc/testsuite/g++.dg/lookup/friend23.C b/gcc/testsuite/g++.dg/lookup/friend23.C
new file mode 100644
index 00000000000..f7b26c9e3ae
--- /dev/null
+++ b/gcc/testsuite/g++.dg/lookup/friend23.C
@@ -0,0 +1,17 @@
+template <class Derived>
+struct base {
+  friend void bar(Derived& d) {
+    d.bar(); // access in inline friend of friend, ok?
+  }
+};
+
+class derived : base<derived> {
+  friend class base<derived>;
+  void bar() {}
+};
+
+int main() {
+  derived d;
+  bar(d);
+}
+
diff --git a/gcc/testsuite/g++.dg/template/access37.C b/gcc/testsuite/g++.dg/template/access37.C
index 5be532c75b0..407a7dc0f2d 100644
--- a/gcc/testsuite/g++.dg/template/access37.C
+++ b/gcc/testsuite/g++.dg/template/access37.C
@@ -6,10 +6,10 @@ struct EnumeratorRange {
     EnumeratorRange range_;
 
     friend void f(Iterator i) {
-      i.range_.end_reached_; // { dg-error "private" }
-      i.range_.EnumeratorRange::end_reached_; // { dg-error "private" }
-      &i.range_.end_reached_; // { dg-error "private" }
-      &i.range_.EnumeratorRange::end_reached_; // { dg-error "private" }
+      i.range_.end_reached_;
+      i.range_.EnumeratorRange::end_reached_;
+      &i.range_.end_reached_;
+      &i.range_.EnumeratorRange::end_reached_;
     }
   };
 
diff --git a/gcc/testsuite/g++.dg/template/friend69.C b/gcc/testsuite/g++.dg/template/friend69.C
index f3086a9f980..9bec6ba5846 100644
--- a/gcc/testsuite/g++.dg/template/friend69.C
+++ b/gcc/testsuite/g++.dg/template/friend69.C
@@ -12,7 +12,7 @@ protected:
 
 struct A {
   friend void g(A) {
-    B::f(); // { dg-error "private" }
-    B::g(); // { dg-error "protected" }
+    B::f();
+    B::g();
   }
 };

base-commit: ce46d6041358052dfa26f3720732f0357c5d72e7
prerequisite-patch-id: 4e382fc8327c2191fe57f2111af0c9830dc85d71
-- 
2.27.0


                 reply	other threads:[~2022-05-15 16:44 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220515164451.3971995-1-jason@redhat.com \
    --to=jason@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).