On 11/13/23 01:02, Iain Sandoe wrote:
The clang compiler supports essentially arbitrary, per-attribute, syntax and
token forms for attribute arguments. This extends to the case where token
forms are required to be accepted that are not part of the valid set for
standard C or C++.
A motivating example (in the initial attribute of this form implemented
in this patch set) is version-style (i.e. x.y.z) numeric values. At present
the c-family cannot handle this, since invalid numeric tokens are rejected
by both C and C++ frontends before we have a chance to decide to accept them
in custom attribute argument parsing.
The solution proposed in this patch series is to allow for a certain set of
attributes names that are known to be 'clang-form' and to defer argument
token validation until the parse of those arguments.
This does not apparently represent any loss of generality - since the
specific attribute names are already claimed by clang and re-using them with
different semantics in GCC would be a highly unfortunate experience for end-
users.
The first patch here adds a mechanism to check attribute identifiers against
a list known to be in clang form. The 'availability' attribute is added as a
first example.
The acceptance of non-standard tokens is constrained to the interval enclosing
the attribute arguments of cases notified as 'clang-form'.
I don't love describing this category as "clang form", I'd prefer
something more descriptive that fits better with the other attribute
argument parsing variants we already have:
/* Values for the second parameter of cp_parser_parenthesized_expression_list.
*/
enum { non_attr = 0, normal_attr = 1, id_attr = 2, assume_attr = 3,
uneval_string_attr = 4 };
Maybe version_num_attr for this?
Jason
