ICE: inlinable function call in a function with debug info must have a !dbg location

[petrochenkov]

Happens at stage 1 during rustc bootstrap with enabled debug info and MIR on Windows/GNU.

./configure --enable-debug --enable-optimize
make rustc-stage1 VERBOSE=1

Result:

CFG_LLVM_LINKAGE_FILE=/home/we/rust/x86_64-pc-windows-gnu/rt/llvmdeps.rs PATH=/home/we/rust/x86_64-pc-windows-gnu/stage1/bin:/home/we/rust/x86_64-pc-windows-gnu/llvm/lib:$PATH   x86_64-pc-windows-gnu/stage1/bin/rustc.exe --cfg stage1  -O --cfg rtopt -C debug-assertions=on -g -C rpath -C prefer-dynamic --target=x86_64-pc-windows-gnu   -L "x86_64-pc-windows-gnu/rt" -L native="C:/msys64/home/we/rust/x86_64-pc-windows-gnu/llvm/lib"     --out-dir x86_64-pc-windows-gnu/stage1/lib/rustlib/x86_64-pc-windows-gnu/lib -C extra-filename=-f53fb285 -C metadata=f53fb285 src/libpanic_unwind/lib.rs
inlinable function call in a function with debug info must have a !dbg location
  call void @rust_eh_unwind_resume(i8* %7)
LLVM ERROR: Broken function found, compilation aborted!
make: *** [/home/we/rust/mk/target.mk:216: x86_64-pc-windows-gnu/stage1/lib/rustlib/x86_64-pc-windows-gnu/lib/stamp.panic_unwind] Error 1

This looks very similar to #35141
cc @eddyb @nagisa

[petrochenkov]

I investigated this a bit, but without much success.
This is a Windows specific problem (custom_unwind_resume == true) happening when the compiled crate contains definition of lang item eh_unwind_resume (lang_items.eh_unwind_resume().is_some()), basically only libpanic_unwind.
cc @vadimcn @alexcrichton maybe you have ideas how to fix this

[eddyb]

@petrochenkov The problem is this line, called from MIR trans. The fix is to move this to the call and use the Builder API instead of bcx.with_block, to get the correct debuginfo applied.

Sorry for not looking into this sooner, #35764 was a priority - we can to start getting rid of all with_block calls after it lands, and even move the smaller remaining pieces of old trans to Builder, too.

[est31]

Sadly, still not fixed yet. Ran into this when wanting to debug strange behaviour on Windows, where printf based debugging actually changed behaviour.

[est31]

@petrochenkov 's workaround of tagging with #[no_debug] worked for me as well.

[eddyb]

It fell through the cracks again, I ended up working solely on higher-up parts of the compiler.
cc @Mark-Simulacrum Want to take on a small trans rewrite?