[clang] Enable C++11-style attributes in all language modes
This also ignores and deprecates the `-fdouble-square-bracket-attributes` command line flag, which seems to not be used anywhere. At least a code search exclusively found mentions of it in documentation: https://sourcegraph.com/search?q=context:global+-fdouble-square-bracket-attributes+-file:clang/*+-file:test/Sema/*+-file:test/Parser/*+-file:test/AST/*+-file:test/Preprocessor/*+-file:test/Misc/*+archived:yes&patternType=standard&sm=0&groupBy=repo
RFC: https://discourse.llvm.org/t/rfc-enable-c-11-c2x-attributes-in-all-standard-modes-as-an-extension-and-remove-fdouble-square-bracket-attributes
This enables `[[]]` attributes in all C and C++ language modes without warning by default. `-Wc++-extensions` does warn. GCC has enabled this extension in all C modes since GCC 10.
Reviewed By: aaron.ballman, MaskRay
Spies: #clang-vendors, beanz, JDevlieghere, Michael137, MaskRay, sstefan1, jplehr, cfe-commits, lldb-commits, dmgreen, jdoerfert, wenlei, wlei
Differential Revision: https://reviews.llvm.org/D151683
2023-07-22 09:33:55 -07:00
// RUN: %clang_cc1 -triple i386-apple-darwin9 -fsyntax-only -verify %s
2009-03-27 21:06:47 +00:00
2010-06-18 21:30:25 +00:00
__attribute ( ( regparm ( 2 ) ) ) int x0 ( void ) ;
2013-07-30 14:10:17 +00:00
__attribute ( ( regparm ( 1.0 ) ) ) int x1 ( void ) ; // expected-error{{'regparm' attribute requires an integer constant}}
2010-06-18 21:30:25 +00:00
__attribute ( ( regparm ( - 1 ) ) ) int x2 ( void ) ; // expected-error{{'regparm' parameter must be between 0 and 3 inclusive}}
__attribute ( ( regparm ( 5 ) ) ) int x3 ( void ) ; // expected-error{{'regparm' parameter must be between 0 and 3 inclusive}}
2013-07-23 19:30:11 +00:00
__attribute ( ( regparm ( 5 , 3 ) ) ) int x4 ( void ) ; // expected-error{{'regparm' attribute takes one argument}}
2010-06-18 21:30:25 +00:00
void __attribute__ ( ( regparm ( 3 ) ) ) x5 ( int ) ;
void x5 ( int ) ; // expected-note{{previous declaration is here}}
2013-02-21 23:15:05 +00:00
void __attribute__ ( ( regparm ( 2 ) ) ) x5 ( int ) ; // expected-error{{function declared with regparm(2) attribute was previously declared with the regparm(3) attribute}}
[clang] Reject non-declaration C++11 attributes on declarations
For backwards compatiblity, we emit only a warning instead of an error if the
attribute is one of the existing type attributes that we have historically
allowed to "slide" to the `DeclSpec` just as if it had been specified in GNU
syntax. (We will call these "legacy type attributes" below.)
The high-level changes that achieve this are:
- We introduce a new field `Declarator::DeclarationAttrs` (with appropriate
accessors) to store C++11 attributes occurring in the attribute-specifier-seq
at the beginning of a simple-declaration (and other similar declarations).
Previously, these attributes were placed on the `DeclSpec`, which made it
impossible to reconstruct later on whether the attributes had in fact been
placed on the decl-specifier-seq or ahead of the declaration.
- In the parser, we propgate declaration attributes and decl-specifier-seq
attributes separately until we can place them in
`Declarator::DeclarationAttrs` or `DeclSpec::Attrs`, respectively.
- In `ProcessDeclAttributes()`, in addition to processing declarator attributes,
we now also process the attributes from `Declarator::DeclarationAttrs` (except
if they are legacy type attributes).
- In `ConvertDeclSpecToType()`, in addition to processing `DeclSpec` attributes,
we also process any legacy type attributes that occur in
`Declarator::DeclarationAttrs` (and emit a warning).
- We make `ProcessDeclAttribute` emit an error if it sees any non-declaration
attributes in C++11 syntax, except in the following cases:
- If it is being called for attributes on a `DeclSpec` or `DeclaratorChunk`
- If the attribute is a legacy type attribute (in which case we only emit
a warning)
The standard justifies treating attributes at the beginning of a
simple-declaration and attributes after a declarator-id the same. Here are some
relevant parts of the standard:
- The attribute-specifier-seq at the beginning of a simple-declaration
"appertains to each of the entities declared by the declarators of the
init-declarator-list" (https://eel.is/c++draft/dcl.dcl#dcl.pre-3)
- "In the declaration for an entity, attributes appertaining to that entity can
appear at the start of the declaration and after the declarator-id for that
declaration." (https://eel.is/c++draft/dcl.dcl#dcl.pre-note-2)
- "The optional attribute-specifier-seq following a declarator-id appertains to
the entity that is declared."
(https://eel.is/c++draft/dcl.dcl#dcl.meaning.general-1)
The standard contains similar wording to that for a simple-declaration in other
similar types of declarations, for example:
- "The optional attribute-specifier-seq in a parameter-declaration appertains to
the parameter." (https://eel.is/c++draft/dcl.fct#3)
- "The optional attribute-specifier-seq in an exception-declaration appertains
to the parameter of the catch clause" (https://eel.is/c++draft/except.pre#1)
The new behavior is tested both on the newly added type attribute
`annotate_type`, for which we emit errors, and for the legacy type attribute
`address_space` (chosen somewhat randomly from the various legacy type
attributes), for which we emit warnings.
Depends On D111548
Reviewed By: aaron.ballman, rsmith
Differential Revision: https://reviews.llvm.org/D126061
2022-06-15 08:07:23 +02:00
[ [ gnu : : regparm ( 3 ) ] ] void x6 ( int ) ; // expected-note{{previous declaration is here}}
[ [ gnu : : regparm ( 2 ) ] ] void x6 ( int ) ; // expected-error{{function declared with regparm(2) attribute was previously declared with the regparm(3) attribute}}
void x6 [ [ gnu : : regparm ( 3 ) ] ] ( int ) ;
void [ [ gnu : : regparm ( 3 ) ] ] x6 ( int ) ; // expected-warning{{'regparm' only applies to function types; type here is 'void'}}
void x6 ( int ) [ [ gnu : : regparm ( 3 ) ] ] ; // expected-warning{{GCC does not allow the 'regparm' attribute to be written on a type}}
