[PATCH] D141324: [clang] extend external_source_symbol attribute with the USR clause
Alex Lorenz via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed Jan 18 14:52:58 PST 2023
arphaman added inline comments.
================
Comment at: clang/include/clang/Basic/AttrDocs.td:1764
+ the ``external_source_symbol`` attribute with
+ ``__has_attribute(external_source_symbol_with_usr)``.
+
----------------
aaron.ballman wrote:
> erichkeane wrote:
> > arphaman wrote:
> > > aaron.ballman wrote:
> > > > erichkeane wrote:
> > > > > I don't think we can do this. __has_attribute needs to take the actual name of the attribute.
> > > > +1
> > > `__has_attribute(external_source_symbol)` already works but it wouldn't help here as it doesn't tell whether the attribute supports USR or not. Are you saying I should come up with a totally new attribute that accepts USR? That was originally why I had the `__has_feature` check.
> > The typical way of doing this in the standard is to have __has_c_attribute/__has_cpp_attribute return a larger non-zero value for the normal attribute.
> >
> > I suspect we should extend `__has_attribute` to do something similar (that is, allowing Feature Test Macros' for it). Aaron, WDYT?
> > The typical way of doing this in the standard is to have has_c_attribute/has_cpp_attribute return a larger non-zero value for the normal attribute.
>
> Which we expose for the CXX11 and C2X spellings in Attr.td, but don't expose for the `Clang` spelling (easy enough to change).
>
> > I suspect we should extend __has_attribute to do something similar (that is, allowing Feature Test Macros' for it). Aaron, WDYT?
>
> +1, if we don't already do that. This should be handled entirely within Attr.td and ClangAttrEmitter.cpp for a generic solution.
sounds good, I will look into that and will update this patch.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D141324/new/
https://reviews.llvm.org/D141324
More information about the cfe-commits
mailing list