aaron.ballman added inline comments.
================
Comment at: clang/include/clang/Basic/Attr.td:1838-1841
def BTFTag : DeclOrTypeAttr {
let Spellings = [Clang<"btf_tag">];
let Args = [StringArgument<"BTFTag">];
+ let Subjects = SubjectList<[Var, Function, Record, Field, TypedefName],
----------------
What worries me about this is that this is now a decl *or* type attribute and
one of the subjects is a typedef name which can be either a type or a decl.
However, this attribute has no type semantics currently -- the only reason it's
allowed on a type at all is because the Linux kernel seems to use it for cast
operations, but we don't support that (we just parse it and ignore it). But
then what are the semantics when used on a typedef if we want to actually
support that casting case in the future?
(This is one of the reasons why GNU attributes are so incredibly difficult to
use in practice -- their ability to "slide" around to whatever makes the most
sense based on the name of the attribute means you run into these situations
and have to work hard to tease out the desired semantics.)
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D110127/new/
https://reviews.llvm.org/D110127
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
