[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