On 13/01/2014 00:38, Sean Silva wrote:
On Sun, Jan 12, 2014 at 6:53 PM, Aaron Ballman <[email protected]
<mailto:[email protected]>> wrote:
> That's good news -- thanks for confirming.
>
> The feature detection macro itself will still need to have a
different name
> (or some other mechanism) so it can be used compatibly with
existing clang
> deployments, because _has_attribute() currently emits a parse
error instead
> of gracefully returning 0 when passed the new argument syntax:
>
> tmp/attr2.cpp:1:5: error: builtin feature check macro requires a
> parenthesized identifier
> #if __has_attribute(__attribute__((weakref)))
> ^
Good catch. Unfortunately, __has_attribute is really the best
identifier for the macro, so I am loathe to let it go.
Due to the current design of __has_attribute, we can't get away with "
magic" by expanding the non-function-like form into a value that could
be tested. So we would really have to pick a new name if we are
worried about this.
Suggestions on the name are welcome.
Ok, I'll bite:
__has_attribute_written_as([[foo]])
__has_attribute_syntax([[foo]])
__has_attribute_spelling([[foo]])
Another possibility:
__has_any_attribute([[foo]])
The silver lining to any one of these names is that they describe the
new semantics more clearly without overloading the existing feature macro.
With the naming and forward compatibility changes, the proposal appears
to pass the "can we use it in LLVM Compiler.h" sanity check with flying
colours.
As for the question of what to do with the old __has_attribute, ~400
uses show up in an Ohloh code search and I'd be concerned to deprecate
the present usage without strong reason.
Instead of deprecation and code churn, how about restricting and shoring
up the old semantics to match actual usage in the wild? All uses I've
seen on Ohloh so far appear to be checking for GNU attributes only.
It sounds like we're getting close to a plan of action.
Alp.
-- Sean Silva
Regardless of the name picked, if
it's different from __has_attribute, we should deprecate the existing
usage since the proposed implementation is backwards compatible and
the existing __has_attribute is not forwards-compatible.
> For forward compatibility your new version should warn, rather
than emitting
> an error, upon encountering invalid attribute syntaxes that may
be valid in
> future standards or other language dialects (e.g. single-braced
C++/CLI []
> attributes should return 0, indicating "unsupported" rather than
triggering
> a parse error).
I agree, and will implement for the next round.
~Aaron
_______________________________________________
cfe-commits mailing list
[email protected] <mailto:[email protected]>
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
--
http://www.nuanti.com
the browser experts
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
