Support C2x [[]] attributes for C.
authorJoseph Myers <joseph@codesourcery.com>
Thu, 14 Nov 2019 03:49:43 +0000 (03:49 +0000)
committerJoseph Myers <jsm28@gcc.gnu.org>
Thu, 14 Nov 2019 03:49:43 +0000 (03:49 +0000)
commit4e03c3a7c1149a8e43b7a2bfd927945cf1e90d19
tree52ad5537d545cae2bfef8c73f76fee3ba758da47
parenteb270950acbae6f70e3487a6e63a26c1294656b3
Support C2x [[]] attributes for C.

This patch adds support for the C2x [[]] attribute syntax to the C
front end.  Support is only added for C at this point, not for
Objective-C; I intend to add the unbounded lookahead required to
support it for Objective-C in a followup patch, but maybe not in
development stage 1.

The syntax is supported in all relevant places where the standard says
it is supported, but support is not added for the individual
attributes specified in C2x (all of which are optional to support).  I
expect to add support for some of them in followup patches; all except
nodiscard can be mapped directly to the semantics of an existing GNU
attribute (subject to extra checks for invalid usages such as the same
attribute being used more than once inside a single [[]]), and the
fallthrough attribute already works after this patch because of
existing special-case code handling it (but without some of the checks
for invalid usage being present).

Note that the four functions c_token_starts_declspecs,
c_token_starts_declaration, c_parser_next_token_starts_declspecs and
c_parser_next_tokens_start_declaration do *not* accept "[[".  This is
analogous with the handling of __extension__: both cases have the
property that they can start either a declaration or some other
statements and so need an unbounded number of tokens to be parsed in
the caller before it can find out what kind of syntactic construct
follows.  Note also that, while I updated all places calling those
functions for standard C syntax to handle attributes if applicable, I
did not do anything regarding calls to such functions for OpenMP or
OpenACC constructs.  Thus, if there are such constructs using such
functions where "[[" *should* be accepted as a possible start to a
declaration, the code for parsing those constructs should be updated
accordingly.

Although all cases of the syntax are handled, and attributes applied
to the constructs the standard says they should be (with less laxity
than there is for GNU attributes to allow an attribute applied to one
construct to be moved automatically to another one), there is a major
limitation in the existing language-independent code in attribs.c
preventing most cases of type attributes from working.  The following
code has been present with minor changes since the first support for
[[]] attributes for C++ was added:

      if (TYPE_P (*node)
          && cxx11_attr_p
          && !(flags & ATTR_FLAG_TYPE_IN_PLACE))
        {
          /* This is a c++11 attribute that appertains to a
             type-specifier, outside of the definition of, a class
             type.  Ignore it.  */
          auto_diagnostic_group d;
          if (warning (OPT_Wattributes, "attribute ignored"))
            inform (input_location,
                    "an attribute that appertains to a type-specifier "
                    "is ignored");
          continue;
        }

I see no justification for this in general for either C or C++ and so
propose to remove or restrict it in a followup bug-fix patch.  Both C
and C++ are clear about attributes in certain places (at the end of
declaration specifiers, or after function or array declarators)
appertaining to a specific type (and explicitly say, in the case of
attributes at the end of declaration specifiers, that they only apply
for that particular use of that type, not for subsequent uses of the
same type without the attributes).  Thus it seems clear to me that,
for example,

int [[gnu::mode(DI)]] x;

ought to be accepted as an analogue in [[]] syntax for

int __attribute__((mode(DI))) x;

(or strictly as an analogue for a version of that with extra
parentheses to make the GNU attribute bind properly to the type rather
than being automatically moved from the declaration to the type).
There are certain cases where an attribute *does* only make sense for
the definition of a type (e.g. "packed" on structure types), but those
should already be handled in the individual attribute handlers (such
as handle_packed_attribute, which already has code to deal with that
issue).  So my inclination is that the above-quoted check in attribs.c
should simply be removed, but failing that it should be restricted to
structure and union types (and such a change would be a bug-fix).
That would then allow various cases of [[]] attributes on types to
work properly.

Bootstrapped with no regressions on x86_64-pc-linux-gnu.

gcc/c:
* c-tree.h (enum c_typespec_kind): Add ctsk_tagref_attrs and
ctsk_tagfirstref_attrs.
(struct c_declspecs): Update description of attrs.  Add
postfix_attrs and non_std_attrs_seen_p.  Increase size of
typespec_kind bit-field.
(c_warn_unused_attributes): New declaration.
(parser_xref_tag): Update prototype.
* c-decl.c (c_warn_unused_attributes): New function.
(shadow_tag_warned): Handle ctsk_tagfirstref_attrs and
ctsk_tagref_attrs.  Handle attribute declarations.
(check_compound_literal_type): Handle ctsk_tagfirstref_attrs.
(grokdeclarator): Handle standard attributes.
(parser_xref_tag): Add arguments have_std_attrs and attrs.  Apply
attributes to incomplete type reference.
(xref_tag): Update call to parser_xref_tag.
(declspecs_add_addrspace, declspecs_add_type)
(declspecs_add_scspec, declspecs_add_attrs): Set
non_std_attrs_seen_p.
(finish_declspecs): Apply postfix standard attributes to type.
* c-parser.c (c_token_starts_declspecs)
(c_token_starts_declaration, c_parser_next_token_starts_declspecs)
(c_parser_next_tokens_start_declaration): Update comments.
(c_parser_consume_token, c_parser_consume_pragma): Handle moving
parser->tokens[2] to parser->tokens[1].
(c_parser_nth_token_starts_std_attributes)
(c_parser_std_attribute_specifier_sequence): New functions.
(c_parser_declaration_or_fndef): Add arguments have_attrs and
attrs.  All callers changed.  Handle standard attributes.
(c_parser_parms_declarator, c_parser_parms_list_declarator)
(c_parser_parameter_declaration): Add argument have_gnu_attrs.
All callers changed.
(c_parser_declspecs): Add arguments start_std_attr_ok and
end_std_attr_ok.  All callers changed.  Handle standard
attributes.
(c_parser_enum_specifier, c_parser_struct_or_union_specifier)
(c_parser_direct_declarator, c_parser_direct_declarator_inner)
(c_parser_compound_statement_nostart, c_parser_all_labels)
(c_parser_label, c_parser_statement, c_parser_for_statement):
Handle standard attributes.
* c-parser.h (c_parser_declspecs): Update prototype.
* gimple-parser.c (c_parser_gimple_declaration): Update call to
c_parser_declspecs.

gcc/testsuite:
* gcc.dg/c2x-attr-fallthrough-1.c, gcc.dg/c2x-attr-syntax-1.c,
gcc.dg/c2x-attr-syntax-2.c, gcc.dg/c2x-attr-syntax-3.c,
gcc.dg/gnu2x-attr-syntax-1.c, gcc.dg/gnu2x-attr-syntax-2.c,
gcc.dg/gnu2x-attrs-1.c: New tests.

From-SVN: r278194
14 files changed:
gcc/c/ChangeLog
gcc/c/c-decl.c
gcc/c/c-parser.c
gcc/c/c-parser.h
gcc/c/c-tree.h
gcc/c/gimple-parser.c
gcc/testsuite/ChangeLog
gcc/testsuite/gcc.dg/c2x-attr-fallthrough-1.c [new file with mode: 0644]
gcc/testsuite/gcc.dg/c2x-attr-syntax-1.c [new file with mode: 0644]
gcc/testsuite/gcc.dg/c2x-attr-syntax-2.c [new file with mode: 0644]
gcc/testsuite/gcc.dg/c2x-attr-syntax-3.c [new file with mode: 0644]
gcc/testsuite/gcc.dg/gnu2x-attr-syntax-1.c [new file with mode: 0644]
gcc/testsuite/gcc.dg/gnu2x-attr-syntax-2.c [new file with mode: 0644]
gcc/testsuite/gcc.dg/gnu2x-attrs-1.c [new file with mode: 0644]