[cfe-dev] "__device_builtin__" attribute ignored by clang AST matcher

[Aaron Ballman via cfe-dev]

On Wed, Jul 29, 2020 at 8:14 PM David Rector <davrecthreads at gmail.com> wrote:
> > On Jul 29, 2020, at 10:07 AM, Aaron Ballman via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> >
> > On Wed, Jul 29, 2020 at 8:47 AM Oliver Zhang via cfe-dev
> > <cfe-dev at lists.llvm.org> wrote:
> >>
> >> Hi,
> >>
> >> I'd like to use the clang AST matcher to match the "__device_builtin__" attribute (ie, "__attribute__((device_builtin))") in pre-processed cuda code, but it seems that the matcher just ignores the attribute. (In clang/Sema/AttrParsedAttrKinds.inc, "AttributeCommonInfo::IgnoredAttribute" is returned upon __device_builtin__.)
> >>
> >> Can anyone please provide any information on how to customize the matcher to match the ignored attribute?
> >
> > I suspect you cannot match against the ignored attribute because
> > ignored attributes are not typically retained by the AST:
> > https://godbolt.org/z/4v574o
>
> FWIW, I think it should be retained.  If we are already retaining loads of type sugar nodes, which like ignored attributes have no effect on semantics, why not just make it a policy to keep a representation of all written syntax in the AST?

I agree, up to a point. C++ and C-style attributes using [[]], where
appertainment is clear based on the syntactic location of the
attribute would be plausible to retain in the AST because we know what
AST node to attach the attribute to. However, for GNU-style
__attribute__ syntax, the picture is less clear because the syntactic
placement of the attribute is insufficient to determine what AST node
to attach the attribute to (some GNU attributes silently "slide" to a
"better" position based on the specific attribute).

> In fact, I would even go so far as to say macro expansions should be represented in the AST, or at least any with balanced delimiters — we could have Decl & Stmt & Expr "sugar" nodes akin to what a TypedefType is for Types.  But I grant that would be a bigger step.

The expanded form of the macro is what forms the AST nodes and we
retain information about whether a given source location is a result
of a macro expansion or not, so I think we already have this
information retained but without having to increase the size of the
AST to do so. But maybe I'm envisioning something differently than you
are here.

~Aaron

>
> >
> > Or are you finding that the AST has the attribute but it's not
> > matching (perhaps because of handling  __device_builtin__ vs
> > device_builtin differently in the AST matchers)?
> >
> > ~Aaron
> >
> >>
> >> Thanks,
> >> Oliver
> >> _______________________________________________
> >> cfe-dev mailing list
> >> cfe-dev at lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>