[WIP] [DebugInfoMetadata] Introduce the "lambda" DISubprogram field

[djtodoro]

Summary

Introduce the DW_AT_LLVM_lambda_name

The proposed attribute points to the name of the lambda expression from C++ source code.

Let’s compile a basic C++ code using a lambda expression with CLANG:

$ cat basic.cpp
#include <iostream>
int main()
{
 auto printNum = [](int num) {
   std::cout << num << '\n';
 };
 for (int i = 0; i < 5; ++i)
   printNum(i);
 return 0;
}
$ clang++ -g -O2  basic.cpp
 

Basically, before this set of patches a debug session on this simple example looks like:

$ gdb a.out
...
Breakpoint 1 at 0x401195: file basic.cpp, line 6.
(gdb) r
Starting program: a.out
Breakpoint 1, main::$_0::operator() (this=<optimized out>, num=0) at basic.cpp:6
6 std::cout << num << '\n';
(gdb) bt
#0 main::$_0::operator() (this=<optimized out>, num=0) at basic.cpp:6
#1 main () at basic.cpp:10

Using the lldb is not much better since we are missing the info from compiler:

$ lldb a.out
...
(lldb) bt
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
* frame #0: 0x0000000000401195 a.out`main [inlined] main::$_0::operator(this=<unavailable>, num=0)(int) const at basic.cpp:6:15
frame #1: 0x0000000000401190 a.out`main at basic.cpp:10
frame #2: 0x00007ffff7a961e3 libc.so.6`__libc_start_main + 243
frame #3: 0x00000000004010ce a.out`_start + 46

Currently, debuggers print mangled name (main::$_0::operator), which is not that useful in this backtrace.
After applying the set of patches and using the LLDB, debugging session on the same test case looks:

$ clang++ -glldb -O2 basic.cpp
$ lldb a.out
..
(lldb) bt
* thread #1, name = ‘a.out’, stop reason = breakpoint 1.1
* frame #0: 0x0000000000401195 a.out `main [inlined] [lambda] printNum(this=<unavailable>, num=0) at basic.cpp:6:15 [opt]  //<== by adding this feature, I was able to add the [lambda] attribute and the name of lambda ‘printNum’//
frame #1: 0x0000000000401190 a.out `main at basic.cpp:10 [opt]
frame #2: 0x00007ffff7a961e3 libc.so.6`__libc_start_main + 243
frame #3: 0x00000000004010ce a.out _start + 46

The GCC + GDB combination does a bit better job when processing lambdas. GCC adds hardcoded DW_AT_name “<lambda>” of corresponding DWARF TAG, referring to the type created for the lambda expression. That is not proposed by DWARF standard, but GDB knows how to parse it and print that into the backtrace.

[djtodoro]

I should have introduced this as an RFC, but I have changed my email and it looks like that @llvm-dev admins have not approved my request yet.
If this makes sense, I could make the RFC. We may want to start the discussion on @dwarf mailing list as well, since something like this could be standardized and used through various tools using DWARF (compilers, debuggers, etc.).

[djtodoro]

I realized this when debugging LLVM by using debuggers (also noticed the GCC does a bit better job). I wrote this code in hurry, so I have not cleaned up/refactored the code and there are some (I think 6) test cases failing.

[dblaikie]

Yeah, please hold on all these patches & wait until you're approved to post to llvm-dev and have a discussion there. I'd worry that the design discussion might get fragmented amongst these threads (& lost amongst the noise of llvm-commits in general).

Some starter questions, though - at least:

1. why does this need different support (in IR, in LLVM, etc) rather than using the existing "Name" field, if there's a more suitable name than the current one
2. could you show the GCC+GDB behavior & contrast it with LLVM's (Clang+GDB/Clang+LLDB, etc) - what I could see didn't look too bad/different between Clang and GCC to me
3. you mention "the lambda name" a few times, but lambdas don't have names - it looks like the name of the enclosing function is being used in some way? From what I can see from GCC and Clang's output (using Clang ToT, and GCC built from source/ToT at 2020/1/11) neither give the lambda type (DW_TAG_structure_type) a DW_AT_name at all, and LLVM/Clang doesn't name the ctor/dtor (whereas GCC names them "<lambda>" and "~<lambda>") and Clang and GCC both name the actual operator() "operator()" - so it's not looking all that different?

[djtodoro]

@dblaikie Thanks a lot for the comments!

Yeah, please hold on all these patches & wait until you're approved to post to llvm-dev and have a discussion there. I'd worry > that the design discussion might get fragmented amongst these threads (& lost amongst the noise of llvm-commits in general).

I strongly agree. I am now subscribed to the @llvm-dev with the new email, but I think I'll be away from keyboard for a few days. When I am back I'll make the RFC for sure.

First of all to summarize lambdas:

1. lambda is an expression
2. a closure is the object (runtime object) created by a lambda
3. a closure is being instantiated from a class called closure class (for each lambda, compilers generate a unique closure class)

Sorry for the confusion. Naming is hard, but I was mistaken when calling it "lambda_name". Lambdas do not have names, and that should be something like: "enclosing_function/method_name".

Some starter questions, though - at least:

1. why does this need different support (in IR, in LLVM, etc) rather than using the existing "Name" field, if there's a more suitable name than the current one

I thought adding something (lambda) specific to this DISubprogram representing the enclosing function can help debuggers to print some additional info in the final backtrace (such as [inlined] [lambda] from the example I shared).

2. could you show the GCC+GDB behavior & contrast it with LLVM's (Clang+GDB/Clang+LLDB, etc) - what I could see didn't look too bad/different between Clang and GCC to me

I use gcc --version == g++ (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008
For a (closure class) type representing a lambda, GCC generates DW_TAG_structure_type with DW_AT_name <lambda(int)>, LLVM/Clang does not generate anything "lambda specific" within corresponding DW_TAG_class_type (clang generates that TAG for the closure class). As a consequence, for the GGC compiled example, we end up with the backtrace like:

...
(gdb) bt
#0  <lambda(int)>::operator()
...

but for LLVM/Clang generated exe:

...
#0  main::$_0::operator()
...

For example, If we have two closures within main():

--using gcc:
   -I was not able to print info about the frame that comes from the second closure (it prints nothing)
 --using clang:
   -It produces a subprogram with mangled name such as ($_2, $_3, etc.):
  	...
 	#0  main::$_2::operator()
      ...

I think that these names are not that useful to end users when using debuggers. The output that GCC+GDB produces is more useful, but I think that having a standardized way of representing this would be desirable (with enclosing_function/method_name after this patch set, LLDB was able to print the name of enclosing function in the backtrace; the alternative is using regular DW_AT_name, but to introduce a flag within the closure class indicating that it comes from a lambda, i.e. DW_AT_lambda, instead of hard coding the name "lambda<>" within the tag representing the type).

3. you mention "the lambda name" a few times, but lambdas don't have names - it looks like the name of the enclosing function is being used in some way?

I wrote it in hurry, sorry, I was mistaken. As I said above, that should be something like "enclosing_function/method_name".

From what I can see from GCC and Clang's output (using Clang ToT, and GCC built from source/ToT at 2020/1/11) neither give the lambda type (DW_TAG_structure_type) a DW_AT_name at all

Actually it does. I use GCC 9.2, and it adds a name within the tag representing the type.

, and LLVM/Clang doesn't name the ctor/dtor (whereas GCC names them "<lambda>" and "~<lambda>") and Clang and GCC both name the actual operator() "operator()" - so it's not looking all that different?

That is very similar, except LLVM/Clang does not name the ctor/dtor, but I think it is not that important.

[dblaikie]

Some starter questions, though - at least:

1. why does this need different support (in IR, in LLVM, etc) rather than using the existing "Name" field, if there's a more suitable name than the current one

I thought adding something (lambda) specific to this DISubprogram representing the enclosing function can help debuggers to print some additional info in the final backtrace (such as [inlined] [lambda] from the example I shared).

2. could you show the GCC+GDB behavior & contrast it with LLVM's (Clang+GDB/Clang+LLDB, etc) - what I could see didn't look too bad/different between Clang and GCC to me

I use gcc --version == g++ (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008
For a (closure class) type representing a lambda, GCC generates DW_TAG_structure_type with DW_AT_name <lambda(int)>, LLVM/Clang does not generate anything "lambda specific" within corresponding DW_TAG_class_type (clang generates that TAG for the closure class). As a consequence, for the GGC compiled example, we end up with the backtrace like:

...
(gdb) bt
#0  <lambda(int)>::operator()

Ah, seems that's changed upstream since 9.2 - in current ToT GCC no name is produced so far as I've been able to reproduce:

0x0000004f: DW_TAG_structure_type

DW_AT_byte_size       (0x01)
DW_AT_decl_file       ("/usr/local/google/home/blaikie/dev/scratch/lambda.cpp")
DW_AT_decl_line       (3)
DW_AT_decl_column     (0x14)
DW_AT_sibling (0x0000010d)

The ctor/dtor still use the "<lambda>" name in them, FWIW.

The stack frame is "operator()" with no scope/context.

...

but for LLVM/Clang generated exe:

...
#0  main::$_0::operator()
...

For example, If we have two closures within main():

--using gcc:
   -I was not able to print info about the frame that comes from the second closure (it prints nothing)

Can you provide complete reproduction steps to clarify the scenarios in each case (in this one, what exactly you mean by "prints nothing" and which frames in which places, etc) - source listings, GDB/LLDB command line logs, etc. Minimal examples as much as possible.

--using clang:
  -It produces a subprogram with mangled name such as ($_2, $_3, etc.):
 	...
	#0  main::$_2::operator()
     ...

I think that these names are not that useful to end users when using debuggers. The output that GCC+GDB produces is more useful, but I think that having a standardized way of representing this would be desirable (with enclosing_function/method_name after this patch set, LLDB was able to print the name of enclosing function in the backtrace; the alternative is using regular DW_AT_name, but to introduce a flag within the closure class indicating that it comes from a lambda, i.e. DW_AT_lambda, instead of hard coding the name "lambda<>" within the tag representing the type).

What about the line and file number associated with these functions/function calls? Is that not useful/adequate to disambiguate the lambda, etc?

3. you mention "the lambda name" a few times, but lambdas don't have names - it looks like the name of the enclosing function is being used in some way?

I wrote it in hurry, sorry, I was mistaken. As I said above, that should be something like "enclosing_function/method_name".

From what I can see from GCC and Clang's output (using Clang ToT, and GCC built from source/ToT at 2020/1/11) neither give the lambda type (DW_TAG_structure_type) a DW_AT_name at all

Actually it does. I use GCC 9.2, and it adds a name within the tag representing the type.

, and LLVM/Clang doesn't name the ctor/dtor (whereas GCC names them "<lambda>" and "~<lambda>") and Clang and GCC both name the actual operator() "operator()" - so it's not looking all that different?

That is very similar, except LLVM/Clang does not name the ctor/dtor, but I think it is not that important.

[djtodoro]

@dblaikie Thanks for your comments! I've been away for a few days, sorry the late response!

In D77799#1974504, @dblaikie wrote:

Some starter questions, though - at least:

1. why does this need different support (in IR, in LLVM, etc) rather than using the existing "Name" field, if there's a more suitable name than the current one

I thought adding something (lambda) specific to this DISubprogram representing the enclosing function can help debuggers to print some additional info in the final backtrace (such as [inlined] [lambda] from the example I shared).

2. could you show the GCC+GDB behavior & contrast it with LLVM's (Clang+GDB/Clang+LLDB, etc) - what I could see didn't look too bad/different between Clang and GCC to me

I use gcc --version == g++ (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008
For a (closure class) type representing a lambda, GCC generates DW_TAG_structure_type with DW_AT_name <lambda(int)>, LLVM/Clang does not generate anything "lambda specific" within corresponding DW_TAG_class_type (clang generates that TAG for the closure class). As a consequence, for the GGC compiled example, we end up with the backtrace like:

...
(gdb) bt
#0  <lambda(int)>::operator()

Ah, seems that's changed upstream since 9.2 - in current ToT GCC no name is produced so far as I've been able to reproduce:

0x0000004f: DW_TAG_structure_type

DW_AT_byte_size       (0x01)
DW_AT_decl_file       ("/usr/local/google/home/blaikie/dev/scratch/lambda.cpp")
DW_AT_decl_line       (3)
DW_AT_decl_column     (0x14)
DW_AT_sibling (0x0000010d)

The ctor/dtor still use the "<lambda>" name in them, FWIW.

The stack frame is "operator()" with no scope/context.

Yes, that is the case. I am using a newer version that comes along with the Ubuntu 19.10:

$ g++ --version
g++ (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

...

but for LLVM/Clang generated exe:

...
#0  main::$_0::operator()
...

For example, If we have two closures within main():

--using gcc:
   -I was not able to print info about the frame that comes from the second closure (it prints nothing)

Can you provide complete reproduction steps to clarify the scenarios in each case (in this one, what exactly you mean by "prints nothing" and which frames in which places, etc) - source listings, GDB/LLDB command line logs, etc. Minimal examples as much as possible.

Sure. I'll try to picture that within next comment.

--using clang:
  -It produces a subprogram with mangled name such as ($_2, $_3, etc.):
 	...
	#0  main::$_2::operator()
     ...

I think that these names are not that useful to end users when using debuggers. The output that GCC+GDB produces is more useful, but I think that having a standardized way of representing this would be desirable (with enclosing_function/method_name after this patch set, LLDB was able to print the name of enclosing function in the backtrace; the alternative is using regular DW_AT_name, but to introduce a flag within the closure class indicating that it comes from a lambda, i.e. DW_AT_lambda, instead of hard coding the name "lambda<>" within the tag representing the type).

What about the line and file number associated with these functions/function calls? Is that not useful/adequate to disambiguate the lambda, etc?

Hmm, good idea. I have not tried something like that, but I feel like a flag (lambda specific flag) would be still missing for some verbose output.

3. you mention "the lambda name" a few times, but lambdas don't have names - it looks like the name of the enclosing function is being used in some way?

I wrote it in hurry, sorry, I was mistaken. As I said above, that should be something like "enclosing_function/method_name".

From what I can see from GCC and Clang's output (using Clang ToT, and GCC built from source/ToT at 2020/1/11) neither give the lambda type (DW_TAG_structure_type) a DW_AT_name at all

Actually it does. I use GCC 9.2, and it adds a name within the tag representing the type.

, and LLVM/Clang doesn't name the ctor/dtor (whereas GCC names them "<lambda>" and "~<lambda>") and Clang and GCC both name the actual operator() "operator()" - so it's not looking all that different?

That is very similar, except LLVM/Clang does not name the ctor/dtor, but I think it is not that important.

[djtodoro]

I tried to make some basic cases showing the current stage with lambdas.

Let's consider two simple C++ cases using lambdas.
The files are attached.

single_lambda.cpp164 BDownload

multiple_lambdas_call.cpp283 BDownload

Using GCC

$ g++ --version
g++ (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

single_lambda.cpp:

$ g++ single_lambda.cpp -g -O2 -o gcc-single-lambda-call
$ gdb gcc-single-lambda-call
...
#0  <lambda(int)>::operator()
...

lldb does not parse the <lambda(int)> part:

$ lldb gcc-single-lambda-call
...
* frame #0: 0x00005555555550e7 gcc-single-lambda-call`main [inlined] operator(...
...

multiple_lambdas_call.cpp:

$ g++ multiple_lambdas_call.cpp -g -O2 -o gcc-multiple-lambdas-call
$ gdb gcc-multiple-lambdas-call
...
(gdb) b 6
(gdb) r
...
(gdb) bt
#0  <lambda(int)>::operator() ...
...

but stopping into the second lambda 'printnum2()' gives us this backtrace (there is no "frame" about second lambda within that backtrace):

...
(gdb) b 10
(gdb) r
...
(gdb) bt
#0  main () at multiple_lambdas_call.cpp:13
...

lldb outputs a smiliar backtrace.

Using CLANG

Using the Trunk version of LLVM/Clang.

single_lambda.cpp:

$ clang++ -g -O2 single_lambda.cpp -o clang-single-lambda-call
$ gdb clang-single-lambda-call
...
(gdb) b 6
(gdb) r
...
(gdb) bt
#0  main::$_0::operator()
...

$ lldb clang-single-lambda-call
...
(lldb) bt
...
  * frame #0: 0x0000000000401195 clang-single-lambda-call`main [inlined] main::$_0::operator(...

multiple_lambdas_call.cpp:

$ clang++ -g -O2 multiple_lambdas_call.cpp -o clang-multiple-lambdas-calls
...
(gdb) b 10
...
(gdb) r
...
(gdb) bt
#0  main::$_1::operator()
...

lldb outputs a smiliar backtrace.

With the patched (by applying this set of patches) LLVM/Clang and lldb, we have:

single_lambda.cpp:

$ clang++ -glldb -O2 single_lambda.cpp -o clang-patched-single-lambda
$ lldb ./clang-patched-single-lambda
...
(lldb) b 6
...
(lldb) r
...
(lldb) bt
...
  * frame #0: 0x0000000000401195 clang-patched-single-lambda`main [inlined] [lambda] printNum(this=<unavailable>, num=0)
...

[dblaikie]

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?")

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.

[djtodoro]

@dblaikie Thanks a lot for your feedback!

In 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.

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.

[dblaikie]

In D77799#2004665, @djtodoro wrote:

@dblaikie Thanks a lot for your feedback!

In 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)

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.

[djtodoro]

In D77799#2006201, @dblaikie wrote:

In D77799#2004665, @djtodoro wrote:

@dblaikie Thanks a lot for your feedback!

In 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.

clang/include/clang/AST/DeclBase.h

public:
   /// getParent - Returns the containing DeclContext.
   DeclContext *getParent() {
     return cast<Decl>(this)->getDeclContext();
   }
   const DeclContext *getParent() const {
     return const_cast<DeclContext*>(this)->getParent();
   }
 
+  // Get the first declaration.
+  Decl *getFirstDeclaration() const {
+    return FirstDecl;
+  }
+
   /// getLexicalParent - Returns the containing lexical DeclContext. May be
   /// different from getParent, e.g.:
   ///
   ///   namespace A {
   ///      struct S;
   ///   }
   ///   struct A::S {}; // getParent() == namespace 'A'
   ///                   // getLexicalParent() == translation unit

clang/lib/CodeGen/CGDebugInfo.cpp

 
 void CGDebugInfo::EmitFunctionStart(GlobalDecl GD, SourceLocation Loc,
                                     SourceLocation ScopeLoc, QualType FnType,
                                     llvm::Function *Fn, bool CurFuncIsThunk,
                                     CGBuilderTy &Builder) {
 
   StringRef Name;
   StringRef LinkageName;
+  StringRef LambdaName;
 
   FnBeginRegionCount.push_back(LexicalBlockStack.size());
 
   const Decl *D = GD.getDecl();
   bool HasDecl = (D != nullptr);
 
   llvm::DINode::DIFlags Flags = llvm::DINode::FlagZero;
   llvm::DISubprogram::DISPFlags SPFlags = llvm::DISubprogram::SPFlagZero;
if (Fn->hasLocalLinkage())
     SPFlags |= llvm::DISubprogram::SPFlagLocalToUnit;
   if (CGM.getLangOpts().Optimize)
     SPFlags |= llvm::DISubprogram::SPFlagOptimized;
 
   llvm::DINode::DIFlags FlagsForDef = Flags | getCallSiteRelatedAttrs();
   llvm::DISubprogram::DISPFlags SPFlagsForDef =
       SPFlags | llvm::DISubprogram::SPFlagDefinition;
 
+  // Check if it is the operator() of a lambda.
+  // TODO: This should be done clearer.
+  if (Name == "operator()") {
+    if (D) {
+      auto CXXMethod = dyn_cast<CXXMethodDecl>(D);
+      if (CXXMethod) {
+        auto ParentDecl = CXXMethod->getParent();
+        if (ParentDecl->isLambda()) {
+          auto LamdaVarDecl = ParentDecl->getParent()->getFirstDeclaration();
+          if (LamdaVarDecl) {
+            LambdaName = cast<VarDecl>(LamdaVarDecl)->getName();
+          }
+        }
+      }
+    }
+  }
+
   unsigned LineNo = getLineNumber(Loc);
   unsigned ScopeLine = getLineNumber(ScopeLoc);
   llvm::DISubroutineType *DIFnType = getOrCreateFunctionType(D, FnType, Unit);
   llvm::DISubprogram *Decl = nullptr;
   if (D)
     Decl = isa<ObjCMethodDecl>(D)
                ? getObjCMethodDeclaration(D, DIFnType, LineNo, Flags, SPFlags)
                : getFunctionDeclaration(D);
 
   // FIXME: The function declaration we're constructing here is mostly reusing
   // declarations from CXXMethodDecl and not constructing new ones for arbitrary
   // FunctionDecls. When/if we fix this we can have FDContext be TheCU/null for
   // all subprograms instead of the actual context since subprogram definitions
   // are emitted as CU level entities by the backend.
   llvm::DISubprogram *SP = DBuilder.createFunction(
       FDContext, Name, LinkageName, Unit, LineNo, DIFnType, ScopeLine,
-      FlagsForDef, SPFlagsForDef, TParamsArray.get(), Decl);
+      FlagsForDef, SPFlagsForDef, TParamsArray.get(), Decl, nullptr, LambdaName);
   Fn->setSubprogram(SP);
   // We might get here with a VarDecl in the case we're generating
   // code for the initialization of globals. Do not record these decls
   // as they will overwrite the actual VarDecl Decl in the cache.
   if (HasDecl && isa<FunctionDecl>(D))
     DeclCache[D->getCanonicalDecl()].reset(SP);
 
   // Push the function onto the lexical block stack.

clang/test/CodeGenCXX/dbg-info-lambda-name.cpp

+// Test the DW_AT_LLVM_lambda_name.
+
+// RUN: %clangxx -S -emit-llvm -g -O2 %s -o - \
+// RUN:      | FileCheck %s
+
+extern void fn(int);
+
+int fn2() {
+  auto doSomething = [](int num) {
+    fn(num);
+  };
+
+  for (int i = 0; i < 5; ++i)
+    doSomething(i);
+
+  return 0;
+}
+
+// CHECK: DISubprogram(name: "operator()", {{.*}}, lambda: "doSomething")

llvm/include/llvm/IR/DIBuilder.h

public:
     /// \param ThrownTypes   Exception types this function may throw.
     DISubprogram *
     createFunction(DIScope *Scope, StringRef Name, StringRef LinkageName,
                    DIFile *File, unsigned LineNo, DISubroutineType *Ty,
                    unsigned ScopeLine, DINode::DIFlags Flags = DINode::FlagZero,
                    DISubprogram::DISPFlags SPFlags = DISubprogram::SPFlagZero,
                    DITemplateParameterArray TParams = nullptr,
                    DISubprogram *Decl = nullptr,
-                   DITypeArray ThrownTypes = nullptr);
+                   DITypeArray ThrownTypes = nullptr,
+                   StringRef Lamda = "");
 
     /// Identical to createFunction,
     /// except that the resulting DbgNode is meant to be RAUWed.
     DISubprogram *createTempFunctionFwdDecl(
         DIScope *Scope, StringRef Name, StringRef LinkageName, DIFile *File,
         unsigned LineNo, DISubroutineType *Ty, unsigned ScopeLine,
         DINode::DIFlags Flags = DINode::FlagZero,
         DISubprogram::DISPFlags SPFlags = DISubprogram::SPFlagZero,

llvm/include/llvm/IR/DebugInfoMetadata.h

private:
 
   static DISubprogram *
   getImpl(LLVMContext &Context, DIScope *Scope, StringRef Name,
           StringRef LinkageName, DIFile *File, unsigned Line,
           DISubroutineType *Type, unsigned ScopeLine, DIType *ContainingType,
           unsigned VirtualIndex, int ThisAdjustment, DIFlags Flags,
           DISPFlags SPFlags, DICompileUnit *Unit,
           DITemplateParameterArray TemplateParams, DISubprogram *Declaration,
-          DINodeArray RetainedNodes, DITypeArray ThrownTypes,
+          DINodeArray RetainedNodes, DITypeArray ThrownTypes, StringRef Lambda,
           StorageType Storage, bool ShouldCreate = true) {
     return getImpl(Context, Scope, getCanonicalMDString(Context, Name),
                    getCanonicalMDString(Context, LinkageName), File, Line, Type,
                    ScopeLine, ContainingType, VirtualIndex, ThisAdjustment,
                    Flags, SPFlags, Unit, TemplateParams.get(), Declaration,
-                   RetainedNodes.get(), ThrownTypes.get(), Storage,
-                   ShouldCreate);
+                   RetainedNodes.get(), ThrownTypes.get(),
+                   getCanonicalMDString(Context, Lambda), Storage, ShouldCreate);
   }
   static DISubprogram *getImpl(LLVMContext &Context, Metadata *Scope,
                                MDString *Name, MDString *LinkageName,
                                Metadata *File, unsigned Line, Metadata *Type,
                                unsigned ScopeLine, Metadata *ContainingType,
                                unsigned VirtualIndex, int ThisAdjustment,
                                DIFlags Flags, DISPFlags SPFlags, Metadata *Unit,
                                Metadata *TemplateParams, Metadata *Declaration,
                                Metadata *RetainedNodes, Metadata *ThrownTypes,
+                               MDString *Lambda,
                                StorageType Storage, bool ShouldCreate = true);
 
   TempDISubprogram cloneImpl() const {
     return getTemporary(getContext(), getScope(), getName(), getLinkageName(),
                         getFile(), getLine(), getType(), getScopeLine(),
                         getContainingType(), getVirtualIndex(),
                         getThisAdjustment(), getFlags(), getSPFlags(),
                         getUnit(), getTemplateParams(), getDeclaration(),
-                        getRetainedNodes(), getThrownTypes());
+                        getRetainedNodes(), getThrownTypes(), getLambda());
   }
 
 public:
   DEFINE_MDNODE_GET(
       DISubprogram,
       (DIScope * Scope, StringRef Name, StringRef LinkageName, DIFile *File,
        unsigned Line, DISubroutineType *Type, unsigned ScopeLine,
        DIType *ContainingType, unsigned VirtualIndex, int ThisAdjustment,
        DIFlags Flags, DISPFlags SPFlags, DICompileUnit *Unit,
        DITemplateParameterArray TemplateParams = nullptr,
        DISubprogram *Declaration = nullptr, DINodeArray RetainedNodes = nullptr,
-       DITypeArray ThrownTypes = nullptr),
+       DITypeArray ThrownTypes = nullptr, StringRef Lambda = ""),
       (Scope, Name, LinkageName, File, Line, Type, ScopeLine, ContainingType,
        VirtualIndex, ThisAdjustment, Flags, SPFlags, Unit, TemplateParams,
-       Declaration, RetainedNodes, ThrownTypes))
+       Declaration, RetainedNodes, ThrownTypes, Lambda))
 
   DEFINE_MDNODE_GET(
       DISubprogram,
       (Metadata * Scope, MDString *Name, MDString *LinkageName, Metadata *File,
        unsigned Line, Metadata *Type, unsigned ScopeLine,
        Metadata *ContainingType, unsigned VirtualIndex, int ThisAdjustment,
        DIFlags Flags, DISPFlags SPFlags, Metadata *Unit,
        Metadata *TemplateParams = nullptr, Metadata *Declaration = nullptr,
-       Metadata *RetainedNodes = nullptr, Metadata *ThrownTypes = nullptr),
+       Metadata *RetainedNodes = nullptr, Metadata *ThrownTypes = nullptr,
+       MDString *Lambda = nullptr),
       (Scope, Name, LinkageName, File, Line, Type, ScopeLine, ContainingType,
        VirtualIndex, ThisAdjustment, Flags, SPFlags, Unit, TemplateParams,
-       Declaration, RetainedNodes, ThrownTypes))
+       Declaration, RetainedNodes, ThrownTypes, Lambda))
 
   TempDISubprogram clone() const { return cloneImpl(); }
 
   /// Returns a new temporary DISubprogram with updated Flags
   TempDISubprogram cloneWithFlags(DIFlags NewFlags) const {
     auto NewSP = clone();
     NewSP->Flags = NewFlags;
     return NewSP;
public:
   }
   DINodeArray getRetainedNodes() const {
     return cast_or_null<MDTuple>(getRawRetainedNodes());
   }
   DITypeArray getThrownTypes() const {
     return cast_or_null<MDTuple>(getRawThrownTypes());
   }
 
+  StringRef getLambda() const {
+    if (auto *s = getRawLambda()) {
+      return s->getString();
+    }
+    return StringRef();
+  }
+
   Metadata *getRawScope() const { return getOperand(1); }
   MDString *getRawName() const { return getOperandAs<MDString>(2); }
   MDString *getRawLinkageName() const { return getOperandAs<MDString>(3); }
   Metadata *getRawType() const { return getOperand(4); }
   Metadata *getRawUnit() const { return getOperand(5); }
   Metadata *getRawDeclaration() const { return getOperand(6); }
   Metadata *getRawRetainedNodes() const { return getOperand(7); }
   Metadata *getRawContainingType() const {
     return getNumOperands() > 8 ? getOperandAs<Metadata>(8) : nullptr;
   }
   Metadata *getRawTemplateParams() const {
     return getNumOperands() > 9 ? getOperandAs<Metadata>(9) : nullptr;
   }
   Metadata *getRawThrownTypes() const {
     return getNumOperands() > 10 ? getOperandAs<Metadata>(10) : nullptr;
   }
 
+  MDString *getRawLambda() const {
+    return getNumOperands() > 11 ? getOperandAs<MDString>(11) : nullptr;
+  }
+
   /// Check if this subprogram describes the given function.
   ///
   /// FIXME: Should this be looking through bitcasts?
   bool describes(const Function *F) const;
 
   static bool classof(const Metadata *MD) {
     return MD->getMetadataID() == DISubprogramKind;
   }

llvm/lib/AsmParser/LLParser.cpp

 
 /// ParseDISubprogram:
 ///   ::= !DISubprogram(scope: !0, name: "foo", linkageName: "_Zfoo",
 ///                     file: !1, line: 7, type: !2, isLocal: false,
 ///                     isDefinition: true, scopeLine: 8, containingType: !3,
 ///                     virtuality: DW_VIRTUALTIY_pure_virtual,
 ///                     virtualIndex: 10, thisAdjustment: 4, flags: 11,
 ///                     spFlags: 10, isOptimized: false, templateParams: !4,
-///                     declaration: !5, retainedNodes: !6, thrownTypes: !7)
+///                     declaration: !5, retainedNodes: !6, thrownTypes: !7,
+///                     lambda: "doSomething")
 bool LLParser::ParseDISubprogram(MDNode *&Result, bool IsDistinct) {
   auto Loc = Lex.getLoc();
 #define VISIT_MD_FIELDS(OPTIONAL, REQUIRED)                                    \
   OPTIONAL(scope, MDField, );                                                  \
   OPTIONAL(name, MDStringField, );                                             \
   OPTIONAL(linkageName, MDStringField, );                                      \
   OPTIONAL(file, MDField, );                                                   \
   OPTIONAL(line, LineField, );                                                 \
   OPTIONAL(type, MDField, );                                                   \
   OPTIONAL(isLocal, MDBoolField, );                                            \
   OPTIONAL(isDefinition, MDBoolField, (true));                                 \
   OPTIONAL(scopeLine, LineField, );                                            \
   OPTIONAL(containingType, MDField, );                                         \
   OPTIONAL(virtuality, DwarfVirtualityField, );                                \
   OPTIONAL(virtualIndex, MDUnsignedField, (0, UINT32_MAX));                    \
   OPTIONAL(thisAdjustment, MDSignedField, (0, INT32_MIN, INT32_MAX));          \
   OPTIONAL(flags, DIFlagField, );                                              \
   OPTIONAL(spFlags, DISPFlagField, );                                          \
   OPTIONAL(isOptimized, MDBoolField, );                                        \
   OPTIONAL(unit, MDField, );                                                   \
   OPTIONAL(templateParams, MDField, );                                         \
   OPTIONAL(declaration, MDField, );                                            \
   OPTIONAL(retainedNodes, MDField, );                                          \
-  OPTIONAL(thrownTypes, MDField, );
+  OPTIONAL(thrownTypes, MDField, );                                            \
+  OPTIONAL(lambda, MDStringField, );
   PARSE_MD_FIELDS();
 #undef VISIT_MD_FIELDS
 
   // An explicit spFlags field takes precedence over individual fields in
   // older IR versions.
   DISubprogram::DISPFlags SPFlags =
       spFlags.Seen ? spFlags.Val
                    : DISubprogram::toSPFlags(isLocal.Val, isDefinition.Val,
                                              isOptimized.Val, virtuality.Val);
   if ((SPFlags & DISubprogram::SPFlagDefinition) && !IsDistinct)
     return Lex.Error(
         Loc,
         "missing 'distinct', required for !DISubprogram that is a Definition");
   Result = GET_OR_DISTINCT(
       DISubprogram,
       (Context, scope.Val, name.Val, linkageName.Val, file.Val, line.Val,
        type.Val, scopeLine.Val, containingType.Val, virtualIndex.Val,
        thisAdjustment.Val, flags.Val, SPFlags, unit.Val, templateParams.Val,
-       declaration.Val, retainedNodes.Val, thrownTypes.Val));
+       declaration.Val, retainedNodes.Val, thrownTypes.Val, lambda.Val));
   return false;
 }
 
 /// ParseDILexicalBlock:
 ///   ::= !DILexicalBlock(scope: !0, file: !2, line: 7, column: 9)
 bool LLParser::ParseDILexicalBlock(MDNode *&Result, bool IsDistinct) {
 #define VISIT_MD_FIELDS(OPTIONAL, REQUIRED)                                    \
   REQUIRED(scope, MDField, (/* AllowNull */ false));                           \

llvm/lib/Bitcode/Reader/MetadataLoader.cpp

case bitc::METADATA_SUBPROGRAM: {
     if (!HasSPFlags && HasUnit && Record.size() < 19)
       return error("Invalid record");
     if (HasSPFlags && !HasUnit)
       return error("Invalid record");
     // Accommodate older formats.
     bool HasFn = false;
     bool HasThisAdj = true;
     bool HasThrownTypes = true;
+    bool HasLambda = true;
     unsigned OffsetA = 0;
     unsigned OffsetB = 0;
     if (!HasSPFlags) {
       OffsetA = 2;
       OffsetB = 2;
       if (Record.size() >= 19) {
         HasFn = !HasUnit;
         OffsetB++;
       }
       HasThisAdj = Record.size() >= 20;
       HasThrownTypes = Record.size() >= 21;
+      HasLambda = Record.size() >= 22;
     }
     Metadata *CUorFn = getMDOrNull(Record[12 + OffsetB]);
     DISubprogram *SP = GET_OR_DISTINCT(
         DISubprogram,
         (Context,
          getDITypeRefOrNull(Record[1]),                     // scope
          getMDString(Record[2]),                            // name
          getMDString(Record[3]),                            // linkageName
          getMDOrNull(Record[4]),                            // file
          Record[5],                                         // line
          getMDOrNull(Record[6]),                            // type
          Record[7 + OffsetA],                               // scopeLine
          getDITypeRefOrNull(Record[8 + OffsetA]),           // containingType
          Record[10 + OffsetA],                              // virtualIndex
          HasThisAdj ? Record[16 + OffsetB] : 0,             // thisAdjustment
          Flags,                                             // flags
          SPFlags,                                           // SPFlags
          HasUnit ? CUorFn : nullptr,                        // unit
          getMDOrNull(Record[13 + OffsetB]),                 // templateParams
          getMDOrNull(Record[14 + OffsetB]),                 // declaration
          getMDOrNull(Record[15 + OffsetB]),                 // retainedNodes
          HasThrownTypes ? getMDOrNull(Record[17 + OffsetB])
-                        : nullptr                           // thrownTypes
+                        : nullptr,                          // thrownTypes
+         HasLambda      ? getMDString(Record[18 + OffsetB])
+                        : nullptr                           // lambda
          ));
     MetadataList.assignValue(SP, NextMetadataNo);
     NextMetadataNo++;
 
     // Upgrade sp->function mapping to function->sp mapping.
     if (HasFn) {
       if (auto *CMD = dyn_cast_or_null<ConstantAsMetadata>(CUorFn))
         if (auto *F = dyn_cast<Function>(CMD->getValue())) {

llvm/lib/Bitcode/Writer/BitcodeWriter.cpp

void ModuleBitcodeWriter::writeDISubprogram(const DISubprogram *N,
   Record.push_back(N->getVirtualIndex());
   Record.push_back(N->getFlags());
   Record.push_back(VE.getMetadataOrNullID(N->getRawUnit()));
   Record.push_back(VE.getMetadataOrNullID(N->getTemplateParams().get()));
   Record.push_back(VE.getMetadataOrNullID(N->getDeclaration()));
   Record.push_back(VE.getMetadataOrNullID(N->getRetainedNodes().get()));
   Record.push_back(N->getThisAdjustment());
   Record.push_back(VE.getMetadataOrNullID(N->getThrownTypes().get()));
+  Record.push_back(VE.getMetadataOrNullID(N->getRawLambda()));
 
   Stream.EmitRecord(bitc::METADATA_SUBPROGRAM, Record, Abbrev);
   Record.clear();
 }
 
 void ModuleBitcodeWriter::writeDILexicalBlock(const DILexicalBlock *N,
                                               SmallVectorImpl<uint64_t> &Record,
                                               unsigned Abbrev) {

llvm/lib/IR/AsmWriter.cpp

static void writeDISubprogram(raw_ostream &Out, const DISubprogram *N,
   Printer.printInt("thisAdjustment", N->getThisAdjustment());
   Printer.printDIFlags("flags", N->getFlags());
   Printer.printDISPFlags("spFlags", N->getSPFlags());
   Printer.printMetadata("unit", N->getRawUnit());
   Printer.printMetadata("templateParams", N->getRawTemplateParams());
   Printer.printMetadata("declaration", N->getRawDeclaration());
   Printer.printMetadata("retainedNodes", N->getRawRetainedNodes());
   Printer.printMetadata("thrownTypes", N->getRawThrownTypes());
+  Printer.printString("lambda", N->getLambda());
   Out << ")";
 }
 
 static void writeDILexicalBlock(raw_ostream &Out, const DILexicalBlock *N,
                                 TypePrinting *TypePrinter, SlotTracker *Machine,
                                 const Module *Context) {
   Out << "!DILexicalBlock(";
   MDFieldPrinter Printer(Out, TypePrinter, Machine, Context);

llvm/lib/IR/DIBuilder.cpp

static DISubprogram *getSubprogram(bool IsDistinct, Ts &&... Args) {
   return DISubprogram::get(std::forward<Ts>(Args)...);
 }
 
 DISubprogram *DIBuilder::createFunction(
     DIScope *Context, StringRef Name, StringRef LinkageName, DIFile *File,
     unsigned LineNo, DISubroutineType *Ty, unsigned ScopeLine,
     DINode::DIFlags Flags, DISubprogram::DISPFlags SPFlags,
     DITemplateParameterArray TParams, DISubprogram *Decl,
-    DITypeArray ThrownTypes) {
+    DITypeArray ThrownTypes, StringRef Lambda) {
   bool IsDefinition = SPFlags & DISubprogram::SPFlagDefinition;
+
   auto *Node = getSubprogram(
       /*IsDistinct=*/IsDefinition, VMContext, getNonCompileUnitScope(Context),
       Name, LinkageName, File, LineNo, Ty, ScopeLine, nullptr, 0, 0, Flags,
       SPFlags, IsDefinition ? CUNode : nullptr, TParams, Decl,
-      MDTuple::getTemporary(VMContext, None).release(), ThrownTypes);
+      MDTuple::getTemporary(VMContext, None).release(), ThrownTypes, Lambda);
 
   if (IsDefinition)
     AllSubprograms.push_back(Node);
   trackIfUnresolved(Node);
   return Node;
 }
 
 DISubprogram *DIBuilder::createTempFunctionFwdDecl(

llvm/lib/IR/DebugInfoMetadata.cpp

 }
 
 DISubprogram *DISubprogram::getImpl(
     LLVMContext &Context, Metadata *Scope, MDString *Name,
     MDString *LinkageName, Metadata *File, unsigned Line, Metadata *Type,
     unsigned ScopeLine, Metadata *ContainingType, unsigned VirtualIndex,
     int ThisAdjustment, DIFlags Flags, DISPFlags SPFlags, Metadata *Unit,
     Metadata *TemplateParams, Metadata *Declaration, Metadata *RetainedNodes,
-    Metadata *ThrownTypes, StorageType Storage, bool ShouldCreate) {
+    Metadata *ThrownTypes, MDString *Lambda,
+    StorageType Storage, bool ShouldCreate) {
   assert(isCanonical(Name) && "Expected canonical MDString");
   assert(isCanonical(LinkageName) && "Expected canonical MDString");
   DEFINE_GETIMPL_LOOKUP(DISubprogram,
                         (Scope, Name, LinkageName, File, Line, Type, ScopeLine,
                          ContainingType, VirtualIndex, ThisAdjustment, Flags,
                          SPFlags, Unit, TemplateParams, Declaration,
-                         RetainedNodes, ThrownTypes));
-  SmallVector<Metadata *, 11> Ops = {
+                         RetainedNodes, ThrownTypes, Lambda));
+  SmallVector<Metadata *, 12> Ops = {
       File,        Scope,         Name,           LinkageName,    Type,       Unit,
-      Declaration, RetainedNodes, ContainingType, TemplateParams, ThrownTypes};
+      Declaration, RetainedNodes, ContainingType, TemplateParams, ThrownTypes, Lambda};
+  if (!Lambda) {
+    Ops.pop_back();
     if (!ThrownTypes) {
       Ops.pop_back();
       if (!TemplateParams) {
         Ops.pop_back();
         if (!ContainingType)
           Ops.pop_back();
       }
     }
+  }
   DEFINE_GETIMPL_STORE_N(
       DISubprogram,
       (Line, ScopeLine, VirtualIndex, ThisAdjustment, Flags, SPFlags), Ops,
       Ops.size());
 }
 
 bool DISubprogram::describes(const Function *F) const {
   assert(F && "Invalid function");

llvm/lib/IR/LLVMContextImpl.h

template <> struct MDNodeKeyImpl<DISubprogram> {
   int ThisAdjustment;
   unsigned Flags;
   unsigned SPFlags;
   Metadata *Unit;
   Metadata *TemplateParams;
   Metadata *Declaration;
   Metadata *RetainedNodes;
   Metadata *ThrownTypes;
+  MDString *Lambda;
 
   MDNodeKeyImpl(Metadata *Scope, MDString *Name, MDString *LinkageName,
                 Metadata *File, unsigned Line, Metadata *Type,
                 unsigned ScopeLine, Metadata *ContainingType,
                 unsigned VirtualIndex, int ThisAdjustment, unsigned Flags,
                 unsigned SPFlags, Metadata *Unit, Metadata *TemplateParams,
                 Metadata *Declaration, Metadata *RetainedNodes,
-                Metadata *ThrownTypes)
+                Metadata *ThrownTypes, MDString *Lambda)
       : Scope(Scope), Name(Name), LinkageName(LinkageName), File(File),
         Line(Line), Type(Type), ScopeLine(ScopeLine),
         ContainingType(ContainingType), VirtualIndex(VirtualIndex),
         ThisAdjustment(ThisAdjustment), Flags(Flags), SPFlags(SPFlags),
         Unit(Unit), TemplateParams(TemplateParams), Declaration(Declaration),
-        RetainedNodes(RetainedNodes), ThrownTypes(ThrownTypes) {}
+        RetainedNodes(RetainedNodes), ThrownTypes(ThrownTypes), Lambda(Lambda) {}
   MDNodeKeyImpl(const DISubprogram *N)
       : Scope(N->getRawScope()), Name(N->getRawName()),
         LinkageName(N->getRawLinkageName()), File(N->getRawFile()),
         Line(N->getLine()), Type(N->getRawType()), ScopeLine(N->getScopeLine()),
         ContainingType(N->getRawContainingType()),
         VirtualIndex(N->getVirtualIndex()),
         ThisAdjustment(N->getThisAdjustment()), Flags(N->getFlags()),
         SPFlags(N->getSPFlags()), Unit(N->getRawUnit()),
         TemplateParams(N->getRawTemplateParams()),
         Declaration(N->getRawDeclaration()),
         RetainedNodes(N->getRawRetainedNodes()),
-        ThrownTypes(N->getRawThrownTypes()) {}
+        ThrownTypes(N->getRawThrownTypes()),
+        Lambda(N->getRawLambda()) {}
 
   bool isKeyOf(const DISubprogram *RHS) const {
     return Scope == RHS->getRawScope() && Name == RHS->getRawName() &&
            LinkageName == RHS->getRawLinkageName() &&
            File == RHS->getRawFile() && Line == RHS->getLine() &&
            Type == RHS->getRawType() && ScopeLine == RHS->getScopeLine() &&
            ContainingType == RHS->getRawContainingType() &&
            VirtualIndex == RHS->getVirtualIndex() &&
            ThisAdjustment == RHS->getThisAdjustment() &&
            Flags == RHS->getFlags() && SPFlags == RHS->getSPFlags() &&
            Unit == RHS->getUnit() &&
            TemplateParams == RHS->getRawTemplateParams() &&
            Declaration == RHS->getRawDeclaration() &&
            RetainedNodes == RHS->getRawRetainedNodes() &&
-           ThrownTypes == RHS->getRawThrownTypes();
+           ThrownTypes == RHS->getRawThrownTypes() &&
+           Lambda == RHS->getRawLambda();
   }
 
   bool isDefinition() const { return SPFlags & DISubprogram::SPFlagDefinition; }
 
   unsigned getHashValue() const {
     // If this is a declaration inside an ODR type, only hash the type and the
     // name.  Otherwise the hash will be stronger than
     // MDNodeSubsetEqualImpl::isDeclarationOfODRMember().

llvm/lib/IR/Verifier.cpp

void Verifier::visitDISubprogram(const DISubprogram &N) {
   if (auto *RawThrownTypes = N.getRawThrownTypes()) {
     auto *ThrownTypes = dyn_cast<MDTuple>(RawThrownTypes);
     AssertDI(ThrownTypes, "invalid thrown types list", &N, RawThrownTypes);
     for (Metadata *Op : ThrownTypes->operands())
       AssertDI(Op && isa<DIType>(Op), "invalid thrown type", &N, ThrownTypes,
                Op);
   }
 
+  // TODO: Verify lambdas.
+
   if (N.areAllCallsDescribed())
     AssertDI(N.isDefinition(),
              "DIFlagAllCallsDescribed must be attached to a definition");
 }
 
 void Verifier::visitDILexicalBlockBase(const DILexicalBlockBase &N) {
   AssertDI(N.getTag() == dwarf::DW_TAG_lexical_block, "invalid tag", &N);
   AssertDI(N.getRawScope() && isa<DILocalScope>(N.getRawScope()),