Drop debug info instead of panicking if we exceed LLVM's capability to represent it

[khuey]

Recapping a bit of history here:

In #128861 I made debug info correctly represent parameters to inline functions by removing a fake lexical block that had been inserted to suppress LLVM assertions and by deduplicating those parameters.

LLVM, however, expects to see a single parameter with distinct locations, particularly distinct inlinedAt values on the DILocations. This generally worked because no matter how deep the chain of inlines it takes two different call sites in the original function to result in the same function being present multiple times, and a function call requires a non-zero number of characters, but macros threw a wrench in that in #131944. At the time I thought the issue there was limited to proc-macros, where an arbitrary amount of code can be generated at a single point in the source text.

In #132613 I added discriminators to DILocations that would otherwise be the same to repair #131944¹. This works, but LLVM's capacity for discriminators is not infinite (LLVM actually only allocates 12 bits for this internally). At the time I thought it would be very rare for anyone to hit the limit, but #132900 proved me wrong. In the relatively-minimized test case it also became clear to me that the issue affects regular macros too, because the call to the inlined function will (without collapse_debuginfo on the macro) be attributed to the (repeated, if the macro is used more than once) textual callsite in the macro definition.

This PR fixes the panic by dropping debug info when we exceed LLVM's maximum discriminator value. There's also a preceding commit for a related but distinct issue: macros that use collapse_debuginfo should in fact have their inlinedAts collapsed to the macro callsite and thus not need discriminators at all (and not panic/warn accordingly when the discriminator limit is exhausted).

Fixes #132900

r? @jieyouxu

Footnotes

1. Editor's note: fix is a magic keyword in PR description that apparently will close the linked issue (it's closed already in this case, but still). ↩

[rustbot]

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

[jieyouxu]

Thanks. This is certainly... interesting. I have two questions.

[jieyouxu]

Question: this is a tracing::warn that is for rustc developers. But shouldn't this be a user-visible warning?

[khuey]

Maybe. It's not particularly actionable to users and we don't warn in all the other cases where we don't emit debug info.

[jieyouxu]

we don't warn in all the other cases where we don't emit debuginfo.

I feel like as a user I would want to have such a warning, but maybe that can get very noisy. Anyway, if we do want to warn when not emitting debuginfo then we should do so consistently, so not for this PR.

EDIT: asked in https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Warning.20if.20not.20emitting.20debuginfo.3F, but not a blocker for this PR.

[jieyouxu]

Otherwise this LGTM, thanks. r=me once PR CI is green.

[jieyouxu]

@bors delegate+ rollup=iffy

[bors]

✌️ @khuey, you can now approve this pull request!

If @jieyouxu told you to "r=me" after making some further change, please make that change, then do @bors r=@jieyouxu

[jieyouxu]

I think tests are not build with debug logging (for good reason), so you cannot include that in the stderr snapshot. I would consider it sufficient to have a test be //@ check-pass, i.e. a test that would've ICE'd without this PR.

[khuey]

Alright, I dropped the warning and adjusted the test accordingly.

@bors r=@jieyouxu

[bors]

📌 Commit f5b023b has been approved by jieyouxu

It is now in the queue for this repository.

[cuviper]

Nominating a backport to follow #132613 -- it seems we should consider these as a pair, backporting both or neither.

@rustbot label beta-nominated

[bors]

⌛ Testing commit f5b023b with merge bcfea1f...

[bors]

☀️ Test successful - checks-actions
Approved by: jieyouxu
Pushing bcfea1f to master...

[rust-timer]

Finished benchmarking commit (bcfea1f): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.1%	[-1.1%, -1.1%]	2
Improvements ✅ (secondary)	-0.4%	[-0.7%, -0.4%]	8
All ❌✅ (primary)	-1.1%	[-1.1%, -1.1%]	2

Max RSS (memory usage)

Results (secondary 3.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.3%	[3.3%, 3.3%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 793.735s -> 793.573s (-0.02%)
Artifact size: 335.41 MiB -> 335.42 MiB (0.00%)

[apiraino]

Beta backport declined as per compiler team on Zulip, since we also declined #132613

@rustbot label -beta-nominated