From: Joseph Myers <joseph@codesourcery.com>
To: David Lamparter <equinox@diac24.net>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] c: don't drop typedef information in casts
Date: Tue, 18 May 2021 20:32:13 +0000 [thread overview]
Message-ID: <alpine.DEB.2.22.394.2105182024310.4027089@digraph.polyomino.org.uk> (raw)
In-Reply-To: <YKOhaZ6aO1T5+0jb@eidolon.nox.tf>
On Tue, 18 May 2021, David Lamparter wrote:
> On Fri, May 07, 2021 at 06:09:35PM +0200, David Lamparter wrote:
> > The TYPE_MAIN_VARIANT() here was, for casts to a typedef'd type name,
> > resulting in all information about the typedef's involvement getting
> > lost. This drops necessary information for warnings and can make them
> > confusing or even misleading. It also makes specialized warnings for
> > unspecified-size system types (pid_t, uid_t, ...) impossible.
>
> Any comments on this? Anything I can do to move this forward? Or is it
> not suitable to be picked up?
Every time I've looked at it, I've been uneasy about the same issue
previously mentioned in review of how the patch looks up names while
processing a cast, which seems very suspicious to me as it did to previous
reviewers - all name lookup should have been done earlier in parsing, not
in the subsequent semantic analysis involved in processing or diagnosing a
cast. If you think there is some reason that late name lookup is either
necessary or correct, it would help to have a rather longer commit message
that explains the reasoning involved at length (patch submissions should
always be self-contained, so include a self-contained commit message
explaining whatever issues may arise in review of the patch, including any
issues from previous reviews that haven't been addressed through changes
to the patch).
Because the name lookup is suspicious, it probably *also* needs
explanation in a comment in the code for why it wasn't done earlier in
parsing.
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2021-05-18 20:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-07 16:09 David Lamparter
2021-05-18 11:13 ` David Lamparter
2021-05-18 20:32 ` Joseph Myers [this message]
-- strict thread matches above, loose matches on Subject: below --
2021-03-10 1:28 David Lamparter
2021-03-10 1:46 ` David Lamparter
2021-03-10 17:01 ` Martin Sebor
2021-03-10 19:02 ` David Lamparter
2021-03-10 19:06 ` David Lamparter
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=alpine.DEB.2.22.394.2105182024310.4027089@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=equinox@diac24.net \
--cc=gcc-patches@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).