Description
As already said here LLVM's inlining pass can sometimes corrupt debuginfo. David Blaikie from the LLVM team kindly helped me clarifying what exactly triggers the issue and how it can be avoided:
The bad stuff happens when a function with debuginfo is inlined at a call-site that has no associated debuginfo. Then the inlined instructions end up with a source location info that does not record that they have been inlined and the codegen will think that it is dealing with corrupt IR. That's when the by now well known LexicalScopes::getOrCreateRegularLexicalScope assertion aborts the process.
The best fix for this is to ensure that we always associate calls and invokes with a debug source location, so the inliner does not trip over them. We already do this most of the time, but one instance where we don't do it reliably is calls to drop glue. If the call is to something without debuginfo (e.g. LLVM intrinsics) then we don't need to be so strict.
Solving this issue will involve looking at all sites where we generate calls and invokes and make sure that debuginfo::set_source_location() is called with the correct arguments right before the call/invoke is emitted.
On the LLVM side an improvement to the debuginfo verifier is in the pipeline which will allow to diagnose this problem more easily in the future.