rustc: Work around DICompileUnit bugs in LLVM

[alexcrichton]

This commit implements a workaround for #46346 which basically just
avoids triggering the situation that LLVM's bug
https://bugs.llvm.org/show_bug.cgi?id=35562 arises. More details can be
found in the code itself but this commit is also intended to ...

Closes#46346

[alexcrichton]

r? @michaelwoerister

[michaelwoerister]

Thanks, Alex!

Do we have some kind of guarantee that the first DICompileUnit is the main one for the given module? Could you please add a check for that?

I'm a bit wary of the consequences of this patch. LLVM does not crash any more but how much will it break line information? I'm OK with merging for now but before we make ThinLTO the default for release builds we should verify that backtraces and basic profiling still work.

Also, we should really push for this being properly fixed in LLVM.

[alexcrichton]

Heh I was hoping you'd know more than I on those topics :)

I'm not actually sure at all what DICompileUnit does in terms of the debugging experience. Currently it looks like we generate things like:

!16 = !DIFile(filename: "foo.rs/@/foo0", directory: "/Users/acrichton/code/rust2")

So given that the file doesn't exist I'd imagine that this wouldn't impact the experience too much. That being said though were there particular things you're worried about? The backtraces do indeed seem to work on OSX (don't have access to Linux right now) but this would also be pretty easy to verify after-the-fact of landing.

[michaelwoerister]

The DICompileUnit sets the base path for things in that compile unit. So if there is a DIFile with a relative path instead of an absolute one then it is interpreted as being relative to the DW_AT_comp_dir that the compile unit specifies.

As far as paths go, we might be in the clear though, since all compile units from the same compilation session with have the same directory there.

[alexcrichton]

Ah excellent points @michaelwoerister! Useful to know for sure that DW_AT_comp_dir is set from this.

I think in that case this may end up working out well? In debug mode this'll never happen because we only generate one codegen unit and ThinLTO isn't used, and then in optimized mode debuginfo is sort of sketchy anyway, but it'd only worsen the experience with debugging the inlined functions from other libraries I think? (which may not have been that great to begin with...)

In that sense perhaps we should merge and see what happens? It's surely easy to turn off quickly :)

[michaelwoerister]

In that sense perhaps we should merge and see what happens?

Yes. If you could find a way to make sure that we keep the "main" DICompileUnit and only throw away the inlined ones then I agree that we should merge and see what happens.

[alexcrichton]

@bors: r=michaelwoerister

[bors]

📌 Commit e0ab5d5 has been approved by michaelwoerister

[bors]

⌛ Testing commit e0ab5d5 with merge de38f49...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: michaelwoerister
Pushing de38f49 to master...

[pnkfelix]

(this might also be a fix for #46505, as noted by@kennytm )