From: Jakub Jelinek <jakub@redhat.com>
To: Jason Merrill <jason@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [RFC PATCH] c++: Minimal handling of carries_dependency attribute
Date: Wed, 9 Nov 2022 13:18:21 +0100 [thread overview]
Message-ID: <Y2uajZKB2Xrjqrtr@tucnak> (raw)
In-Reply-To: <edf3d9d0-04e6-bca6-5fec-fb661fe60766@redhat.com>
On Tue, Nov 08, 2022 at 01:40:03PM -1000, Jason Merrill wrote:
> > A comment in D2552R1:
> > "The only questionable (but still conforming) case we found was
> > [[carries_dependency(some_argument)]] on GCC, where the emitted diagnostic said that the
> > carries_dependency attribute is not supported, but did not specifically call out the syntax error
> > in the argument clause."
> > made me try the following patch, where we'll error at least
> > for arguments to the attribute and for some uses of the attribute
> > appertaining to something not mentioned in the standard warn
> > with different diagnostics (or should that be an error?; clang++
> > does that, but I think we never do for any attribute, standard or not).
> > The diagnostics on toplevel attribute declaration is still an
> > attribute ignored warning and on empty statement different wording.
> >
> > The paper additionally mentions
> > struct X { [[nodiscard]]; }; // no diagnostic on GCC
> > and 2 cases of missing diagnostics on [[fallthrough]] (guess I should
> > file a PR about those; one problem is that do { ... } while (0); there
> > is replaced during genericization just by ... and another that
> > [[fallthrough]] there is followed by a label, but not user/case/default
> > label, but an artificial one created from while loop genericization.
> >
> > Thoughts on this?
>
> LGTM.
Thanks, committed now.
Given CWG2538, I wonder whether we shouldn't at least pedwarn rather than
warning{,_at} for standard attributes that appertain to wrong entities
(and keep warning{,_at} for non-standard attributes including gnu variants
of standard attributes).
If yes, we'd need to differentiate between the standard attributes
and gnu variants thereof (I think the C FE does, but C++ FE has
/* We used to treat C++11 noreturn attribute as equivalent to GNU's,
but no longer: we have to be able to tell [[noreturn]] and
__attribute__((noreturn)) apart. */
/* C++14 deprecated attribute is equivalent to GNU's. */
if (is_attribute_p ("deprecated", attr_id))
TREE_PURPOSE (TREE_PURPOSE (attribute)) = gnu_identifier;
/* C++17 fallthrough attribute is equivalent to GNU's. */
else if (is_attribute_p ("fallthrough", attr_id))
TREE_PURPOSE (TREE_PURPOSE (attribute)) = gnu_identifier;
/* C++23 assume attribute is equivalent to GNU's. */
else if (is_attribute_p ("assume", attr_id))
TREE_PURPOSE (TREE_PURPOSE (attribute)) = gnu_identifier;
so we'd need to remove that and make sure those standard attributes
are handled.
Jakub
next prev parent reply other threads:[~2022-11-09 12:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-08 14:42 Jakub Jelinek
2022-11-08 23:40 ` Jason Merrill
2022-11-09 12:18 ` Jakub Jelinek [this message]
2022-11-10 7:18 ` Jason Merrill
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=Y2uajZKB2Xrjqrtr@tucnak \
--to=jakub@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jason@redhat.com \
/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).