Broken LLVM module: inlinable function call in a function with debug info must have a !dbg location

[DaniPopes]

Code

I tried this code foundry-rs/foundry@0cc5355:

git clone https://github.com/foundry-rs/foundry.git
git checkout 0cc535504a909dcee74694fa86f7faafa4cbf4bc
cargo +stable build --bin forge --profile maxperf # takes a while (>5 min)

I expected to see this happen: compiles like with dev or release profile

Instead, this happened (see https://github.com/foundry-rs/foundry/actions/runs/12700786553/job/35404155023#step:7:3652):

inlinable function call in a function with debug info must have a !dbg location
  tail call fastcc void @_ZN5alloc5alloc18handle_alloc_error17ha0547c441587f574E(i64 noundef 8, i64 noundef 128) #324
... # the last line repeated thousands of times with different arguments
rustc-LLVM ERROR: Broken module found, compilation aborted!

This is caused by the following config combination, as changing any of these values makes it compile again:

debug = "line-tables-only" # any value that's not "none"
lto = "fat"

I've also verified that the strip value does not affect the outcome either.

We fixed this by setting debug = "none".

Maybe related to #129063, which modified the function mentioned in the error?

---

I could reproduce this locally only on 1.84, not on beta or nightly, so feel free to close this if it has already been fixed. Reproducible with RUSTFLAGS="-Zverify-llvm-ir", see #135332 (comment).

Unfortunately I wasn't able to minimize this.

Version it worked on

It most recently worked on: 1.83.0

Version with regression

rustc --version --verbose:

rustc 1.84.0 (9fc6b4312 2025-01-07)
binary: rustc
commit-hash: 9fc6b43126469e3858e2fe86cafb4f0fd5068869
commit-date: 2025-01-07
host: x86_64-unknown-linux-gnu
release: 1.84.0
LLVM version: 19.1.5

rustc 1.86.0-nightly (824759493 2025-01-09)
binary: rustc
commit-hash: 824759493246ee383beb9cd5ceffa0e15deb9fa4
commit-date: 2025-01-09
host: x86_64-unknown-linux-gnu
release: 1.86.0-nightly
LLVM version: 19.1.6

@rustbot modify labels: +regression-from-stable-to-stable -regression-untriaged

[lqd]

Maybe related to #129063, which modified the function mentioned in the error?

That landed in 1.83 so probably not. We can try to bisect, but 5 minutes per step does not sound like a fun time 😓.

[DaniPopes]

That landed in 1.83 so probably not.

Ah sorry, misread the tag in the commit view.

We can try to bisect, but 5 minutes per step does not sound like a fun time

Took about 1 hour, not that bad.

searched nightlies: from nightly-2024-10-13 to nightly-2024-11-22
regressed nightly: nightly-2024-11-11
searched commit range: 59cec72...143ce09
regressed commit: b026d85

bisected with cargo-bisect-rustc v0.6.9

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc --start 1.83.0 --end 1.84.0 -- build --profile maxperf --bin forge 

---

I then bisected b026d85 ... 1.84.0 with --regress no-error

searched toolchains nightly-2024-11-22 through nightly-2025-01-08


********************************************************************************
Regression in nightly-2024-12-02
********************************************************************************

ending github query because we found starting sha: 7442931d49b199ad0a1cc0f8ca54e327b5139b66
get_commits_between returning commits, len: 7
  commit[0] 2024-11-30: Auto merge of #133684 - RalfJung:rollup-j2tmrg7, r=RalfJung
  commit[1] 2024-12-01: Auto merge of #133365 - compiler-errors:compare-impl-item, r=lcnr
  commit[2] 2024-12-01: Auto merge of #133499 - nikic:no-backend-verify, r=Mark-Simulacrum
  commit[3] 2024-12-01: Auto merge of #133694 - matthiaskrgr:rollup-s6xj4rf, r=matthiaskrgr
  commit[4] 2024-12-01: Auto merge of #132390 - RalfJung:diagnostics-root-dir, r=albertlarsan68,weihanglo
  commit[5] 2024-12-01: Auto merge of #133532 - rami3l:ci/bump-ubuntu, r=Kobzol
  commit[6] 2024-12-01: Auto merge of #133703 - matthiaskrgr:rollup-fwlw0mc, r=matthiaskrgr

---

So:

• regression in Add discriminators to DILocations when multiple functions are inlined into a single point. #132613 with an ICE
• ... which was changed to broken LLVM IR in Drop debug info instead of panicking if we exceed LLVM's capability to represent it #133194
• ... which was "fixed" between 1.84 and 1.85 by not verifying LLVM IR in Respect verify-llvm-ir option in the backend #133499

And in fact building with RUSTFLAGS="-Zverify-llvm-ir" on the latest nightly fails compilation with the same LLVM error.

[lqd]

Yup, same, I was bisecting through 2024-11-11 myself.

Let's at least cc the authors of those PRs: @khuey and @nikic.

[khuey]

If you run your -Zverify-llvm-ir stuff on tests/ui/debuginfo/debuginfo-inline-callsite-location-macro-1.rs and tests/ui/debuginfo/debuginfo-inline-callsite-location-macro-2.rs does it trigger on either test?

[nikic]

If you run your -Zverify-llvm-ir stuff on tests/ui/debuginfo/debuginfo-inline-callsite-location-macro-1.rs and tests/ui/debuginfo/debuginfo-inline-callsite-location-macro-2.rs does it trigger on either test?

Unless these tests are skipped in CI, the answer is no.

[nikic]

The usual way to fix this error (assuming that there genuinely no better location that can be attached) is to add a 0-line DILocation. https://reviews.llvm.org/D133095 is one case where I encountered this error before.

[khuey]

Yeah, that's what I plan to do, but I would like to understand the pattern that causes this error if the tests don't.

[DaniPopes]

Managed to create a smaller reproducer here: https://github.com/DaniPopes/rust-bug-135332
Based on https://github.com/buaazp/rust-bug from #132900