If the parent function is inlined into multiple callers, is the outlined subprogram scope treated like any other nested lexical scope and duplicated?
If the outlined subprogram scope is duplicated when inlined, how will retained nodes on the outlined subprogram be handled in this case?
Does CodeViewDebug handle the nested subprogram scoping?
Can you add a test which validates the nested scoping is correct in the DWARF emission (covering the non-clang part of this patch)?

In a similar fashion to how instructions are handled according to Delete an IR-level instruction, when a constant is destroyed and cannot be RAUW'd, updating the debug information uses of the constant to undef seems like the correct approach. LGTM.

Fix the constant name flagged by tidy.

x64 windows > LLVM.Instrumentation/InstrProfiling::profiling.ll
I couldn't find a correlation between my patch and this unit test failure. This maybe related to this commit:
https://github.com/llvm/llvm-project/commit/30ad7b5dadcd90ce8df240f1fa74ee2e98a875dc

Update the patch to validate the section iterator before using it to lookup the section index.

Remove the "TODO" item which is now done.

NFC:
Remove section size checks from the global_visibility test which were used temporarily during development of the patch.
This test is meant to validate the variable scope, not the debug symbols section size.

This patch incorporates all review feedback received thus far.

Updated the patch based on review comments.

Update the tests to use retainedNodes instead of variables following the changes made in rL331841.

Changes committed in rL332296.

In the test inheritance.ll I updated the 'variables' attribute to 'retainedNodes' to reflect the changes recently committed in rL331841.

I think this code would be a lot less confusing if we rename this to something more mechanical like getTypeIdentifier

I changed the routine names, updated the call sites, and made the comment changes.
Please let me know if you like this better.

The indentation seems off which suggests the patch may contain tabs.

Fixed.

The virtual base pointer offset is now encoded in the extraData field of DIDerivedType.

Document a comment I received via email from David to keep everything in one place:

Bitcode files shouldn't generally need updating - because bitcode should be backwards compatible (& indeed usually the only reason bitcode files are checked in is to test and ensure that backwards compatibility guarantee is met)

I updated the patch file to generalize the fix for more than just lambdas.

This patch was reverted in rL327414 due a build bot failure.
It depends upon a fix for C++ lambdas which hasn't landed yet. Once that patch lands, this one will be reapplied exactly as seen here.

Can you add a clang IRGen test that checks the DISubprogram flags set for thunks?

I extended the existing test debug-info-thunk.cpp to make sure the DIFlagThunk flag is set on the thunk routines.

Did this get committed?

Not yet. It looks like I'll have time to commit it on Monday if that is okay?

Did you confirm that when stepping through a program in the debugger that variables are correctly shown in the Autos window depending on the source line?

Yes. When stopping at a machine instruction, only the locals visible from the corresponding lexical scope are displayed.

Thanks everyone for the wonderful feedback! I'm uploading a new diff with the requested changes thus far.
I will provide additional answers for some of the feedback I received after uploading this patch.

I made the changes you requested. Specifically:

• I check for an empty identifier in addition to an empty name on the composite type.
• I updated the code to call report_fatal_error when an unexpected cycle occurs in the type graph.
• I added a lit test containing a cycle in the type graph to make sure the error is caught.

Thank you Reid. I'll make the changes you requested and upload a new patch. Much appreciated.

Unnamed C++ structs are given a name as of rL274401, so unnamed structs containing a method will have a name assigned to them and will not create a cycle in this case.