From: Jason Merrill <jason@redhat.com>
To: priour.be@gmail.com, gcc-patches@gcc.gnu.org
Cc: benjamin priour <vultkayn@gcc.gnu.org>
Subject: Re: [PATCH] c++: Additional warning for name-hiding [PR12341]
Date: Tue, 5 Sep 2023 16:52:13 -0400 [thread overview]
Message-ID: <1a0f7dcf-3aa5-57f1-da86-0adf34b1d50b@redhat.com> (raw)
In-Reply-To: <20230904171858.2660517-1-vultkayn@gcc.gnu.org>
On 9/4/23 13:18, priour.be@gmail.com wrote:
> From: benjamin priour <vultkayn@gcc.gnu.org>
>
> Hi,
>
> This patch was the first I wrote and had been
> at that time returned to me because ill-formatted.
>
> Getting busy with other things, I forgot about it.
> I've now fixed the formatting.
>
> Succesfully regstrapped on x86_64-linux-gnu off trunk
> a7d052b3200c7928d903a0242b8cfd75d131e374.
> Is it OK for trunk ?
>
> Thanks,
> Benjamin.
>
> Patch below.
> ---
>
> Add a new warning for name-hiding. When a class's field
> is named similarly to one inherited, a warning should
> be issued.
> This new warning is controlled by the existing Wshadow.
>
> gcc/cp/ChangeLog:
>
> PR c++/12341
> * search.cc (lookup_member):
> New optional parameter to preempt processing the
> inheritance tree deeper than necessary.
> (lookup_field): Likewise.
> (dfs_walk_all): Likewise.
> * cp-tree.h: Update the above declarations.
> * class.cc: (warn_name_hiding): New function.
> (finish_struct_1): Call warn_name_hiding if -Wshadow.
>
> gcc/testsuite/ChangeLog:
>
> PR c++/12341
> * g++.dg/pr12341-1.C: New file.
> * g++.dg/pr12341-2.C: New file.
>
> Signed-off-by: benjamin priour <vultkayn@gcc.gnu.org>
> ---
> gcc/cp/class.cc | 75 ++++++++++++++++++++++++++++++++
> gcc/cp/cp-tree.h | 9 ++--
> gcc/cp/search.cc | 28 ++++++++----
> gcc/testsuite/g++.dg/pr12341-1.C | 65 +++++++++++++++++++++++++++
> gcc/testsuite/g++.dg/pr12341-2.C | 34 +++++++++++++++
> 5 files changed, 200 insertions(+), 11 deletions(-)
> create mode 100644 gcc/testsuite/g++.dg/pr12341-1.C
> create mode 100644 gcc/testsuite/g++.dg/pr12341-2.C
>
> diff --git a/gcc/cp/class.cc b/gcc/cp/class.cc
> index 778759237dc..b1c59c392a0 100644
> --- a/gcc/cp/class.cc
> +++ b/gcc/cp/class.cc
> @@ -3080,6 +3080,79 @@ warn_hidden (tree t)
> }
> }
>
> +/* Warn about non-static fields name hiding. */
> +
> +static void
> +warn_name_hiding (tree t)
> +{
> + if (is_empty_class (t) || CLASSTYPE_NEARLY_EMPTY_P (t))
> + return;
> +
> + for (tree field = TYPE_FIELDS (t); field; field = DECL_CHAIN (field))
> + {
> + /* Skip if field is not an user-defined non-static data member. */
> + if (TREE_CODE (field) != FIELD_DECL || DECL_ARTIFICIAL (field))
> + continue;
> +
> + unsigned j;
> + tree name = DECL_NAME (field);
> + /* Skip if field is anonymous. */
> + if (!name || !identifier_p (name))
> + continue;
> +
> + auto_vec<tree> base_vardecls;
> + tree binfo;
> + tree base_binfo;
> + /* Iterate through all of the base classes looking for possibly
> + shadowed non-static data members. */
> + for (binfo = TYPE_BINFO (t), j = 0;
> + BINFO_BASE_ITERATE (binfo, j, base_binfo); j++)
Rather than iterate through the bases here, maybe add a mode to
lookup_member/lookup_field_r that skips the most derived type, e.g. by
adding that as a flag in lookup_field_info?
Probably instead of the once_suffices stuff?
> + if (base_vardecl)
> + {
> + auto_diagnostic_group d;
> + if (warning_at (location_of (field), OPT_Wshadow,
> + "%qD might shadow %qD", field, base_vardecl))
Why "might"? We can give a correct answer, we shouldn't settle for an
approximation.
Jason
next prev parent reply other threads:[~2023-09-05 20:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-04 17:18 priour.be
2023-09-05 20:52 ` Jason Merrill [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-04-16 21:33 Benjamin Priour
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=1a0f7dcf-3aa5-57f1-da86-0adf34b1d50b@redhat.com \
--to=jason@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=priour.be@gmail.com \
--cc=vultkayn@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).