Re: [RFC PATCH] c++: Minimal handling of carries_dependency attribute

[Jason Merrill <jason@redhat.com>]

On 11/9/22 02:18, Jakub Jelinek wrote:
> 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).

I don't think that's necessary, but it might be better.  And I guess we 
should separate the warnings for unrecognized attributes vs. misused 
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
>