aaron.ballman added inline comments.
================
Comment at: clang/include/clang/Basic/Attr.td:1435
+ let Spellings = [GCC<"leaf">];
+ let Subjects = SubjectList<[Function]>;
+ let Documentation = [Undocumented];
----------------
gulfem wrote:
> aaron.ballman wrote:
> > gulfem wrote:
> > > aaron.ballman wrote:
> > > > gulfem wrote:
> > > > > aaron.ballman wrote:
> > > > > > Should this attribute also be supported on things like ObjC method
> > > > > > decls or other function-like interfaces?
> > > > > Do I need to do anything else to support this attribute in
> > > > > Objective-C as well?
> > > > > I think we should support it in all the C languages family.
> > > > >I think we should support it in all the C languages family.
> > > >
> > > > That's already happening automatically -- there's a C and C++ spelling
> > > > available for it and the attribute doesn't specify that it requires a
> > > > particular language mode or target.
> > > >
> > > > > Do I need to do anything else to support this attribute in
> > > > > Objective-C as well?
> > > > You can add multiple subjects to the list here, so you can have this
> > > > apply to `Function, ObjCMethod` for both of those. Another one to
> > > > consider is whether this attribute can be written on a block
> > > > declaration (like a lambda, but with different syntax). Beyond that,
> > > > it's mostly just documentation, devising the test cases to ensure the
> > > > ObjC functionality behaves as expected, possibly some codegen changes,
> > > > etc.
> > > AFAIK, users can specify function attributes in lambda expressions.
> > > Lambda functions can only be accessed/called by the functions in the same
> > > translation unit, right?
> > > Leaf attribute does not have any effect on the functions that are defined
> > > in the same translation unit.
> > > For this reason, I'm thinking that leaf attribute would not have any
> > > effect if they are used in lambda expressions.
> > > Do you agree with me?
> > > AFAIK, users can specify function attributes in lambda expressions.
> >
> > I always forget that you can do that for declaration attributes using
> > GNU-style syntax...
> >
> > > Lambda functions can only be accessed/called by the functions in the same
> > > translation unit, right?
> >
> > Not necessarily, you could pass one across TU boundaries like a function
> > pointer, for instance. e.g.,
> > ```
> > // TU1.cpp
> > void foo() {
> > auto l = []() { ... };
> > bar(l);
> > }
> >
> > // TU2.cpp
> > void bar(auto func) {
> > func();
> > }
> > ```
> > Not necessarily, you could pass one across TU boundaries like a function
> > pointer, for instance. e.g.,
> As I mentioned before, leaf attribute is specifically intended for library
> functions and I think all the existing usage of leaf attribute is in the
> library function declarations. For this reason, I think we do not need to
> support them for lambdas. Is that reasonable?
>
> For this reason, I think we do not need to support them for lambdas. Is that
> reasonable?
Is this considered a library function?
```
struct S {
void f(); // Is this a library function?
void operator()(); // How about this?
};
```
If the answer is "no", then I think we only need to support `FunctionDecl` and
nothing else (not even `ObjCMethodDecl`, which is like a member function for
ObjC). If the answer is "yes", then it's not clear to me whether lambdas should
or should not be supported given that the attribute on the lambda expression is
attached to the function call operator for the lambda declaration.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D90275/new/
https://reviews.llvm.org/D90275
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
