From: Patrick Palka <ppalka@redhat.com>
To: Jason Merrill <jason@redhat.com>
Cc: Patrick Palka <ppalka@redhat.com>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] c++: access for hidden friend of nested class template [PR100502]
Date: Tue, 25 May 2021 10:50:24 -0400 (EDT) [thread overview]
Message-ID: <4505f20-6034-9712-937e-2acb3c4fbea@idea> (raw)
In-Reply-To: <02cf0d83-e362-687c-6619-e8b81a7ad872@redhat.com>
On Mon, 24 May 2021, Jason Merrill wrote:
> On 5/21/21 4:35 PM, Patrick Palka wrote:
> > Here, during ahead of time access checking for the private member
> > EnumeratorRange::end_reached_ in the hidden friend f, we're triggering
> > the the assert in enforce_access that verifies we're not trying to add a
> > dependent access check to TI_DEFERRED_ACCESS_CHECKS.
> >
> > The special thing about this class member access expression is that it's
> > considered to be non-type-dependent (so finish_class_member_access_expr
> > doesn't exit early at template parse time), and then accessible_p
> > rejects the access (so we don't exit early from enforce access either,
> > and end up triggering the assert). I think we're correct to reject it
> > because a hidden friend is not a member function, so [class.access.nest]
> > doesn't apply, and also a hidden friend of a nested class is not a
> > friend of the enclosing class. (Note that Clang accepts the testcase
> > and MSVC and ICC reject it.)
>
> Hmm, I think you're right, but that seems inconsistent with the change (long
> ago) to give nested classes access to members of the enclosing class.
I guess the question is whether a hidden friend is considered to be a
class member for sake of access checking. Along that note, I noticed
Clang/GCC/MSVC/ICC all accept the access of A::f in:
struct A {
protected:
static void f();
};
struct B : A {
friend void g() { A::f(); }
};
But arguably this is valid iff g is considered to be a member of B.
If we adjust the above example to define the friend g at namespace
scope:
struct A {
protected:
static void f();
};
struct B : A {
friend void g();
};
void g() { A::f(); }
then GCC/MSVC/ICC accept and Clang rejects. But this second example is
definitely invalid since it's just a special case of the example in
[class.protected], which says:
void fr() {
...
B::j = 5; // error: not a friend of naming class B
...
}
>
> > This patch relaxes the problematic assert in enforce_access to check
> > dependent_scope_p instead of uses_template_parms, which is the more
> > accurate notion of dependence we care about.
>
> Agreed.
>
> > This change alone is
> > sufficient to fix the ICE, but we now end up diagnosing each access
> > twice, once at substitution time and again from TI_DEFERRED_ACCESS_CHECKS.
> > So this patch additionally disables ahead of time access checking
> > during the call to lookup_member from finish_class_member_access_expr;
> > we're going to check the same access again at substitution time anyway.
>
> That seems undesirable; it's better to diagnose when parsing if we can. Why is
> it going on TI_DEFERRED_ACCESS_CHECKS after we already checked it?
At parse time, a negative accessible_p answer only means "maybe not
accessible" rather than "definitely not accessible", since access
may still be granted to some specialization of the current template
via a friend declaration. I think we'd need to beef up accessible_p a
bit before we can begin diagnosing accesses at template parse time.
This probably wouldn't be too hairy to implement; I'll look into it.
For now, would the assert relaxation in enforce_access be OK for
trunk/11?
>
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk? For GCC 11, should we just backport the enforce_access hunk?
> >
> > PR c++/100502
> >
> > gcc/cp/ChangeLog:
> >
> > * semantics.c (enforce_access): Relax assert about the type
> > depedence of the DECL_CONTEXT of the declaration.
> > * typeck.c (finish_class_member_access_expr): Disable ahead
> > of time access checking during the member lookup.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * g++.dg/template/access37.C: New test.
> > * g++.dg/template/access37a.C: New test.
> > ---
> > gcc/cp/semantics.c | 2 +-
> > gcc/cp/typeck.c | 6 ++++++
> > gcc/testsuite/g++.dg/template/access37.C | 26 +++++++++++++++++++++++
> > gcc/testsuite/g++.dg/template/access37a.C | 6 ++++++
> > 4 files changed, 39 insertions(+), 1 deletion(-)
> > create mode 100644 gcc/testsuite/g++.dg/template/access37.C
> > create mode 100644 gcc/testsuite/g++.dg/template/access37a.C
> >
> > diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
> > index 0d590c318fb..0de14316bba 100644
> > --- a/gcc/cp/semantics.c
> > +++ b/gcc/cp/semantics.c
> > @@ -365,7 +365,7 @@ enforce_access (tree basetype_path, tree decl, tree
> > diag_decl,
> > check here. */
> > gcc_assert (!uses_template_parms (decl));
> > if (TREE_CODE (decl) == FIELD_DECL)
> > - gcc_assert (!uses_template_parms (DECL_CONTEXT (decl)));
> > + gcc_assert (!dependent_scope_p (DECL_CONTEXT (decl)));
> > /* Defer this access check until instantiation time. */
> > deferred_access_check access_check;
> > diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
> > index 703ddd3cc7a..86cf26b9c84 100644
> > --- a/gcc/cp/typeck.c
> > +++ b/gcc/cp/typeck.c
> > @@ -3201,9 +3201,15 @@ finish_class_member_access_expr (cp_expr object, tree
> > name, bool template_p,
> > {
> > /* Look up the member. */
> > access_failure_info afi;
> > + if (processing_template_decl)
> > + /* We're going to redo this member lookup at instantiation
> > + time, so don't bother checking access ahead of time here. */
> > + push_deferring_access_checks (dk_no_check);
> > member = lookup_member (access_path, name, /*protect=*/1,
> > /*want_type=*/false, complain,
> > &afi);
> > + if (processing_template_decl)
> > + pop_deferring_access_checks ();
> > afi.maybe_suggest_accessor (TYPE_READONLY (object_type));
> > if (member == NULL_TREE)
> > {
> > diff --git a/gcc/testsuite/g++.dg/template/access37.C
> > b/gcc/testsuite/g++.dg/template/access37.C
> > new file mode 100644
> > index 00000000000..92fed3e97cb
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/template/access37.C
> > @@ -0,0 +1,26 @@
> > +// PR c++/100502
> > +
> > +template <class>
> > +struct EnumeratorRange {
> > + struct Iterator {
> > + 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" }
> > + }
> > + };
> > +
> > + private:
> > + bool end_reached_;
> > +#if DECLARE_FRIEND
> > + friend void f(Iterator);
> > +#endif
> > +};
> > +
> > +int main() {
> > + EnumeratorRange<int>::Iterator i;
> > + f(i);
> > +}
> > diff --git a/gcc/testsuite/g++.dg/template/access37a.C
> > b/gcc/testsuite/g++.dg/template/access37a.C
> > new file mode 100644
> > index 00000000000..4ce1b2718a0
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/template/access37a.C
> > @@ -0,0 +1,6 @@
> > +// PR c++/100502
> > +// { dg-additional-options "-DDECLARE_FRIEND -Wno-non-template-friend" }
> > +
> > +// Verify that access37.C is accepted if the appropriate friend relation
> > +// is declared (controlled by the macro DECLARE_FRIEND).
> > +#include "access37.C"
> >
>
>
next prev parent reply other threads:[~2021-05-25 14:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-21 20:35 Patrick Palka
2021-05-24 21:13 ` Jason Merrill
2021-05-25 14:50 ` Patrick Palka [this message]
2021-05-25 15:18 ` Jason Merrill
2021-05-26 14:31 ` Patrick Palka
2021-05-26 15:29 ` Jason Merrill
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=4505f20-6034-9712-937e-2acb3c4fbea@idea \
--to=ppalka@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jason@redhat.com \
/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).