[clang] [clang-tools-extra] [clang-include-cleaner] Make cleanup attr report expr location (PR #140233)
Erich Keane via cfe-commits
cfe-commits at lists.llvm.org
Mon May 19 11:49:24 PDT 2025
================
@@ -1351,7 +1352,8 @@ def OSConsumesThis : InheritableAttr {
def Cleanup : InheritableAttr {
let Spellings = [GCC<"cleanup">];
- let Args = [DeclArgument<Function, "FunctionDecl">];
+ let Args = [DeclArgument<Function, "FunctionDecl">,
+ ExprArgument<"Expr", /*opt=*/0, /*fake=*/1>];
----------------
erichkeane wrote:
> > I would lean AGAINST 3, unless we have a REALLY good reason to.
>
> Being able to iterate over arguments generically would mean removing a _ton_ of specific logic in places like pretty printing, AST matching, etc. Basically, if `Decl` and `Stmt` let you iterate over its `children()` generically, `Attr` would be good to handle for the same reasons.
>
Hmm... that could definitely be useful to do. A bit of memory pressure though.
> > This would require that Attr have a trailing-objects,
>
> Wha? `ParsedAttr` already tracks this generically, doesn't it? So I was thinking of lifting that onto `AttributeCommonInfo` so that `Attr` gets the benefit too.
It does so as trailing-objects, which we then remove/pass to the `*Attr` ctor's, which are auto generated to be the 'right' type. BUT we use manual checking to do the conversion between teh generic `ArgsUnion` and this.
> But yeah, if this requires a bunch of extra overhead, I'm also opposed -- we want attributes to be cheap rather than memory-hungry given how many of them show up in system headers.
*sigh*, yeah, its a bit of a frustrating balance.
https://github.com/llvm/llvm-project/pull/140233
More information about the cfe-commits
mailing list