Re: [PATCH 1/4] c-family: Add handling for clang-style attributes [PR109877].
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
Re: [PATCH 1/4] c-family: Add handling for clang-style attributes [PR109877].
On 11/12/23 23:02, Iain Sandoe wrote:
This patch set is not actually particualry new, I have been maintaining
it locally one Darwin branches and it has been tested on several versions
of Darwin both with and without Alex's __has_{feature, extension} patch.
This is one of the three most significant blockers to importing the macOS
SDKs properly, and cannot currently be fixincludes-ed (in fact it can not
ever really since the attribute is uaer-facing and so can be in end-user
code that we cannot fix).
OK for trunk?
thanks
Iain
--- 8< ---
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'.
PR c++/109877
gcc/c-family/ChangeLog:
* c-attribs.cc (attribute_clang_form_p): New.
* c-common.h (attribute_clang_form_p): New.
Patches #1-#3 are fine if nobody has objected within say 48hrs.
Basically I agree that we have to do something along the lines of what
you're suggesting and I just want to give folks the opportunity to raise
any implementation issues they may see.
Patch #4 is obviously darwin specific and I think you can self-approve.
Jeff
[PATCH 1/4] c-family: Add handling for clang-style attributes [PR109877].
This patch set is not actually particualry new, I have been maintaining
it locally one Darwin branches and it has been tested on several versions
of Darwin both with and without Alex's __has_{feature, extension} patch.
This is one of the three most significant blockers to importing the macOS
SDKs properly, and cannot currently be fixincludes-ed (in fact it can not
ever really since the attribute is uaer-facing and so can be in end-user
code that we cannot fix).
OK for trunk?
thanks
Iain
--- 8< ---
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'.
PR c++/109877
gcc/c-family/ChangeLog:
* c-attribs.cc (attribute_clang_form_p): New.
* c-common.h (attribute_clang_form_p): New.
Signed-off-by: Iain Sandoe
---
gcc/c-family/c-attribs.cc | 12
gcc/c-family/c-common.h | 1 +
2 files changed, 13 insertions(+)
diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
index 461732f60f7..8c087317f4f 100644
--- a/gcc/c-family/c-attribs.cc
+++ b/gcc/c-family/c-attribs.cc
@@ -615,6 +615,18 @@ attribute_takes_identifier_p (const_tree attr_id)
return targetm.attribute_takes_identifier_p (attr_id);
}
+/* Returns TRUE iff the attribute indicated by ATTR_ID needs its
+ arguments converted to string constants. */
+
+bool
+attribute_clang_form_p (const_tree attr_id)
+{
+ const struct attribute_spec *spec = lookup_attribute_spec (attr_id);
+ if (spec && !strcmp ("availability", spec->name))
+return true;
+ return false;
+}
+
/* Verify that argument value POS at position ARGNO to attribute NAME
applied to function FN (which is either a function declaration or function
type) refers to a function parameter at position POS and the expected type
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index b57e83d7c5d..4dbc566d2b5 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -1535,6 +1535,7 @@ extern void check_for_xor_used_as_pow (location_t
lhs_loc, tree lhs_val,
/* In c-attribs.cc. */
extern bool attribute_takes_identifier_p (const_tree);
extern tree handle_deprecated_attribute (tree *, tree, tree, int, bool *);
+extern bool attribute_clang_form_p (const_tree);
extern tree handle_unused_attribute (tree *, tree, tree, int, bool *);
extern tree handle_fallthrough_attribute (tree *, tree, tree, int, bool *);
extern int parse_tm_stmt_attr (tree, int);
--
2.39.2 (Apple Git-143)
