[PATCH] D77799: [WIP] [DebugInfoMetadata] Introduce the "lambda" DISubprogram field

[Djordje Todorovic via Phabricator via llvm-commits]

djtodoro added a comment.

In D77799#2006201 <https://reviews.llvm.org/D77799#2006201>, @dblaikie wrote:

> In D77799#2004665 <https://reviews.llvm.org/D77799#2004665>, @djtodoro wrote:
>
> > @dblaikie Thanks a lot for your feedback!
> >
> > In D77799#2003175 <https://reviews.llvm.org/D77799#2003175>, @dblaikie wrote:
> >
> > > In general I don't think this is a good idea - not all lambdas end up with variables that refer to them (and the name of that variable isn't the name of the lambda, in any case - that's the thing, the lambda is nameless). (eg: this code crashes on "int main() { [] { }(); }" and produces the wrong answer, for, say "int main() { int narf; []{}(); }" and clang doesn't keep track of reverse edges (there's no list of users of a type, I think?) so it's not possible in general to answer the question of "what, if any, name was used to refer to this lambda?")
> >
> >
> > Basically, this was a //couple-of-days-writting// code, so I've just hardcoded to make it working only for the simple case (//single_lambda.cpp//) (it uses the `firstDecl` from the `AST` which is not the right solution). In addition, I was mistaken when naming it `lambda_name`, since better name would be `name_of_enclosing_func` (or something similar), since lambdas are nameless. Anyhow, after I saw this in front of me, I also realized the `name_of_enclosing_func` is not that useful for all the lambdas, so I think I'll change the approach.
> >  IMPO, **clang** should handle lambdas (at least) the same way the newest **GCC** does (I've shared above how it looks; debugging user experience is obviously better). It may be even improved; I have some ideas, and I'll make a prototype for that as soon as I find some time.
> >  Please let me know what you think.
>
>
> Have you tested against ToT GCC? It looked to me that ToT GCC was closer to/the same as Clang's output & I'm not sure it's better. (GCC prints "<lambda(int)>::operator()" where Clang prints "main::$_0::operator()" - and honestly, the latter seems more informative - about where the lambda comes from)


Hmm, yes, I see.. Something in the middle of these two would be better (if possible):
e.g.

`main::<lambda(int)>::operator()`
or at least we could provide a flag (lambda specific), in order to add an additional info to the frame as so:
 `[inlined] [lambda] main::operator()`

but this is, I think, more appropriate for an RFC.

>>> But if you really want to pursue this, please start a thread on llvm-dev (including the usual suspects - myself, echristo, aprantl, probinson) to discuss how lambda debugging might be improved.
>> 
>> Sure.




CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77799/new/

https://reviews.llvm.org/D77799