debuginfo: IR Call and Invoke instructions must have source location debuginfo

[michaelwoerister]

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.

[michaelwoerister]

I have implemented a fix for this locally, which makes rustc emit debuginfo for all calls and invokes, especially those to drop-glue. The reason why the assertion occurred relatively rarely was that sometimes a drop-glue function was generated by the compiler between setting the debug location state intended for the call instruction and actually emitting the call instruction. Generating the drop-glue would then reset the debug location state, resulting in a call instruction without any debuginfo.

This side-effect based API for debuginfo source location is really rather nasty. We essentially read and write a global variable all the time and hope that nothing bad happens :) I'll have to think about how this situation can be improved.

The implemented fix needs some cleanup and more testing, so it will still take some time until I have pull request ready.

[jdm]

Your diligence is appreciated!