[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