public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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

  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).