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++/99040] [modules] partitions & using declarations
Date: Fri, 12 Feb 2021 21:50:12 +0000	[thread overview]
Message-ID: <bug-99040-4-o8AECtqZjb@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-99040-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #1 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Nathan Sidwell <nathan@gcc.gnu.org>:

https://gcc.gnu.org/g:8f93e1b892850b00bf6b9cbc5711a7d5bc367967

commit r11-7228-g8f93e1b892850b00bf6b9cbc5711a7d5bc367967
Author: Nathan Sidwell <nathan@acm.org>
Date:   Thu Feb 11 13:06:03 2021 -0800

    Expunge namespace-scope IDENTIFIER_TYPE_VALUE & global_type_name [PR 99039]

    IDENTIFIER_TYPE_VALUE and friends is a remnant of G++'s C origins.  It
    holds elaborated types on identifier-nodes.  While this is fine for C
    and for local and class-scopes in C++, it fails badly for namespaces.
    In that case a marker 'global_type_node' was used, which essentially
    signified 'this is a namespace-scope type *somewhere*', and you'd have
    to do a regular name_lookup to find it.  As the parser and
    substitution machinery has avanced over the last 25 years or so,
    there's not much outside of actual name-lookup that uses that.
    Amusingly the IDENTIFIER_HAS_TYPE_VALUE predicate will do an actual
    name-lookup and then users would repeat that lookup to find the
    now-known to be there type.

    Rather late I realized that this interferes with the lazy loading of
    module entities, because we were setting IDENTIFIER_TYPE_VALUE to
    global_type_node.  But we could be inside some local scope where that
    identifier is bound to some local type.  Not good!

    Rather than add more cruft to look at an identifier's shadow stack and
    alter that as necessary, this takes the approach of removing the
    existing cruft.

    We nuke the few places outside of name lookup that use
    IDENTIFIER_TYPE_VALUE.  Replacing them with either proper name
    lookups, alternative sequences, or in some cases asserting that they
    (no longer) happen.  Class template instantiation was calling pushtag
    after setting IDENTIFIER_TYPE_VALUE in order to stop pushtag creating
    an implicit typedef and pushing it, but to get the bookkeeping it
    needed.  Let's just do the bookkeeping directly.

    Then we can stop having a 'bound at namespace-scope' marker at all,
    which means lazy loading won't screw up local shadow stacks.  Also, it
    simplifies set_identifier_type_value_with_scope, as it never needs to
    inspect the scope stack.  When developing this patch, I discovered a
    number of places we'd put an actual namespace-scope type on the
    type_value slot, rather than global_type_node.  You might notice this
    is killing at least two 'why are we doing this?' comments.

    While this doesn't fix the two PRs mentioned, it is a necessary step.

            PR c++/99039
            PR c++/99040
            gcc/cp/
            * cp-tree.h (CPTI_GLOBAL_TYPE): Delete.
            (global_type_node): Delete.
            (IDENTIFIER_TYPE_VALUE): Delete.
            (IDENTIFIER_HAS_TYPE_VALUE): Delete.
            (get_type_value): Delete.
            * name-lookup.h (identifier_type_value): Delete.
            * name-lookup.c (check_module_override): Don't
            SET_IDENTIFIER_TYPE_VALUE here.
            (do_pushdecl): Nor here.
            (identifier_type_value_1, identifier_type_value): Delete.
            (set_identifier_type_value_with_scope): Only
            SET_IDENTIFIER_TYPE_VALUE for local and class scopes.
            (pushdecl_nanmespace_level): Remove shadow stack nadgering.
            (do_pushtag): Use REAL_IDENTIFIER_TYPE_VALUE.
            * call.c (check_dtor_name): Use lookup_name.
            * decl.c (cxx_init_decl_processing): Drop global_type_node.
            * decl2.c (cplus_decl_attributes): Don't SET_IDENTIFIER_TYPE_VALUE
            here.
            * init.c (get_type_value): Delete.
            * pt.c (instantiate_class_template_1): Don't call pushtag or
            SET_IDENTIFIER_TYPE_VALUE here.
            (tsubst): Assert never an identifier.
            (dependent_type_p): Drop global_type_node assert.
            * typeck.c (error_args_num): Don't use IDENTIFIER_HAS_TYPE_VALUE
            to determine ctorness.
            gcc/testsuite/
            * g++.dg/lookup/pr99039.C: New.

  parent reply	other threads:[~2021-02-12 21:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-09 18:31 [Bug c++/99040] New: " nathan at gcc dot gnu.org
2021-02-10 21:05 ` [Bug c++/99040] " nathan at gcc dot gnu.org
2021-02-12 21:50 ` cvs-commit at gcc dot gnu.org [this message]
2021-02-12 21:50 ` cvs-commit at gcc dot gnu.org
2021-02-12 21:51 ` nathan 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-99040-4-o8AECtqZjb@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).