Change:
pub fn maybe_process_path_extern(&mut self, name: Symbol) -> Option<CrateNum> { self.maybe_resolve_crate(name, CrateDepKind::Explicit, None).ok() } <del> pub fn unload_unused_crates(&mut self) { for opt_cdata in &mut self.cstore.metas { if let Some(cdata) = opt_cdata && !cdata.used() { *opt_cdata = None; } } } </del> } fn global_allocator_spans(krate: &ast::Crate) -> Vec<Span> {

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. --Minimal repro: This ICE needs a specific project setup with a that has a doc-comment referencing one of its crate dependencies. The git repo above is a full example, but this will work, too: The error only seems to happen with crates that do not contain hyphens in the name. I don't know, I haven't really dug into it. is a popular crate, it doesn't have any dependencies, and it exhibits the crash. The git repo above has a totally empty dependency named , so it doesn't really matter what the dependency itself contains. <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
searched nightlies: from nightly-2024-02-08 to nightly-2024-02-09 regressed nightly: nightly-2024-02-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsThis looks similar to
Fixed in
We're seeing this panic in our CI as well: I'm working on reproducing it.

<!-- 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. -- Clone the repo and, set run to reproduce the ICE <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details Running points to searched nightlies: from nightly-2024-02-08 to nightly-2024-02-09 regressed nightly: nightly-2024-02-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
From looking at the list of PR's in that rollup PR, it might be So cc
v0.6.5 if you update to 0.6.8 you may be able to bisect the specific merge inside the rollup that caused this :) at least the latest version can do that
Thanks for letting me know. The new output is: searched nightlies: from nightly-2024-02-08 to nightly-2024-02-09 regressed nightly: nightly-2024-02-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsSo yes, that was introduced by
I just want to leave another note here: Using RUSTFLAGS=-Zsanitizer=address is not necessary. You can reproduce this issue with in the linked repo
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Fixed in