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.
next prev 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: linkBe 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).