george.burgess.iv abandoned this revision.
george.burgess.iv added a comment.
r306467 used `__has_extension(overloadable_unmarked)` instead.
Thanks again for the comments!
https://reviews.llvm.org/D33904
___
cfe-commits mailing list
cfe-commits@lis
aaron.ballman added a comment.
In https://reviews.llvm.org/D33904#778165, @george.burgess.iv wrote:
> > Why not just use __has_feature(overloadable_unmarked) or similar?
>
> My impression was that `__has_feature` was was for larger features than
> tweaks to attributes. If this would be an approp
george.burgess.iv added a comment.
> Why not just use __has_feature(overloadable_unmarked) or similar?
My impression was that `__has_feature` was was for larger features than tweaks
to attributes. If this would be an appropriate use of `__has_feature`, though,
I'm happy to keep things simple.
hfinkel added a comment.
I prefer `__has_attribute_feature` to enhancement. I don't see why we need a
new macro for this, however. Why not just use
`__has_feature(overloadable_unmarked)` or similar?
https://reviews.llvm.org/D33904
___
cfe-commits
ahatanak added inline comments.
Comment at: docs/LanguageExtensions.rst:176
+For example, clang's ``overloadable`` attribute has existed since before Clang
+3.5, but in Clang 5.0 it gained was modified to support so-called "unmarked
+overloads". One can use ``__has_attribute_enh
george.burgess.iv created this revision.
Herald added a subscriber: javed.absar.
Attributes may gain features or added flexibility over time. This patch aims to
add a simple and uniform way to directly add/query for arbitrary changes in
attributes, instead of having to rely on other information
