Change:
<del> Subproject commit 57ae1a3474057fead2c438928ed368b3740bf0ec </del> <ins> Subproject commit ccf4c38bdd73f1a37ec266c73bdaef80e39f8cf6 </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --Repro repository and steps: I've bisected between 1.79.0 and 1.80.0: searched nightlies: from nightly-2024-04-28 to nightly-2024-06-07 regressed nightly: nightly-2024-05-10 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.9</summaryHost triple: x8664-pc-windows-msvc Reproduce with: </details<details<summaryOld context</summaryIt's a company project with a workspace that compiles ~680 crates on a clean compile. From initial testing it seems like an incremental compilation bug :S works, fails, but when setting in , succeeds again. also reproduces the issue, dropping the number of crates down to "only" 203. This is our profile config: </details<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --This reproduces on 1.80 and the current nightly (as of writing this ticket). This does not reproduce on 1.79.0. : and <!-- Include a backtrace in the code block by setting in your environment. E.g. . --There is no backtrace being printed, even with . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It's a proprietary code base, but I'll try my best to minimize the dependencies and code and see if I can get to something shareable. If you've got any other ideas on what to test or try, please let me know!
That LLVM metadata in the error looks like the kind that would be used with , but it's particularly surprising to me because as far as I know rustc only ever emits range metadata with a single range in it: might have some guesses here? Not sure why it would be incremental-related, though.
It's weird.

My guess is that it's due to some LLVM Passes.
My first guess here would be a bug in getMostGenericRange(), but at least the basic case seems to work correctly:
Making progress on figuring out the minimal code to comment out to successfully compile again, on the way I've now got this:
Fully-minimized repro: Do note the release profile settings. Run with to repro. with Notes: Reordering the enum variants in Outer fixes it. Reducing the discriminant value of B or C fixes it. fixes it.
Thanks!
Reduced repro even further, with the minimal B and C values (thx Reduce them any further and the error is gone. Also removed the slice and replaced with just an equals check (since the bisect pointed to a check anyway)
Very interesting, I can trigger random crashes locally at stage 1, for example:
Never really looked at LLVM IR before, but guessing by what posted with the metadata: According to : The generated IR between 1.79.0 and 1.80.0 has changed significantly for builds. Rust 1.80.0, : Rust 1.80.0, Rust 1.79.0,
Ah, the minimal reproducible example is: (But I'm going to bed.
IIUC, this should be :
Upstreamed issue: claim
This can happen in any version: