public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/58993] incorrectly accept access of protected member method from derived class template
Date: Tue, 19 Jan 2021 21:20:27 +0000	[thread overview]
Message-ID: <bug-58993-4-268j5ep5jF@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-58993-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:29853c653245c37ed31b6abcc9799b534372e938

commit r11-6800-g29853c653245c37ed31b6abcc9799b534372e938
Author: Patrick Palka <ppalka@redhat.com>
Date:   Tue Jan 19 16:20:00 2021 -0500

    c++: Always check access during late-parsing of members [PR58993]

    This patch removes a vestigial use of dk_no_check from
    cp_parser_late_parsing_for_member, which ideally should have been
    removed as part of the PR41437 patch that improved access checking
    inside templates.  This allows us to correctly reject f1 and f2 in
    the testcase access34.C below (whereas before we'd only reject f3).

    Additional testing revealed a new access issue when late-parsing a hidden
    friend within a class template.  In the testcase friend68.C below, we're
    tripping over the checking assert from friend_accessible_p(f, S::j, S, S)
    during lookup of j in x.j (for which type_dependent_object_expression_p
    returns false, which is why we're doing the lookup at parse time).  The
    reason for the assert failure is that DECL_FRIENDLIST(S) contains f but
    DECL_BEFRIENDING_CLASSES(f) is empty, and so friend_accessible_p (which
    looks at DECL_BEFRIENDING_CLASSES) wants to return false, but is_friend
    (which looks at DECL_FRIENDLIST) returns true.

    For sake of symmetry one would expect that DECL_BEFRIENDING_CLASSES(f)
    contains S, but add_friend avoids updating DECL_BEFRIENDING_CLASSES when
    the class type (S in this case) is dependent, for some reason.

    This patch works around this issue by making friend_accessible_p
    consider the DECL_FRIEND_CONTEXT of the access scope.  Thus we sidestep
    the DECL_BEFRIENDING_CLASSES / DECL_FRIENDLIST asymmetry issue while
    correctly validating the x.j access at parse time.

    A earlier version of this patch checked friend_accessible_p instead of
    protected_accessible_p in the DECL_FRIEND_CONTEXT hunk below, but this
    had the side effect of making us accept the ill-formed testcase friend69.C
    below (ill-formed because the hidden friend g is not actually a member
    of A, so g doesn't have access to B's members despite B befriending A).

    gcc/cp/ChangeLog:

            PR c++/41437
            PR c++/58993
            * search.c (friend_accessible_p): If scope is a hidden friend
            defined inside a dependent class, consider access from the
            class.
            * parser.c (cp_parser_late_parsing_for_member): Don't push a
            dk_no_check access state.

    gcc/testsuite/ChangeLog:

            PR c++/41437
            PR c++/58993
            * g++.dg/opt/pr87974.C: Adjust.
            * g++.dg/template/access34.C: New test.
            * g++.dg/template/friend68.C: New test.
            * g++.dg/template/friend69.C: New test.

  parent reply	other threads:[~2021-01-19 21:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-04 23:52 [Bug c++/58993] New: failure to access pointer to protected member method in base from derived class specialization cvs at cs dot utoronto.ca
2013-11-05 11:59 ` [Bug c++/58993] incorrectly accept access of protected member method from derived class template redi at gcc dot gnu.org
2013-11-05 13:37 ` cvs at cs dot utoronto.ca
2021-01-12 16:58 ` ppalka at gcc dot gnu.org
2021-01-19 21:20 ` cvs-commit at gcc dot gnu.org [this message]
2021-01-20 14:52 ` ppalka at gcc dot gnu.org
2022-05-15 16:45 ` cvs-commit at gcc dot gnu.org
2022-06-02 13:29 ` ppalka at gcc dot gnu.org

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=bug-58993-4-268j5ep5jF@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@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).