Missing ICE info after some compiler panics

[jruderman]

Several panic messages changed recently:

• With the panic in ICE with mismatch in trait associated constant #105632, the output now ends immediately after the stack trace. The information about how to report an ICE is missing, and the query stack is also missing.
• With the panic in ICE: unwrap on None in find_cycle_in_stack #105321, the output now includes "panic in a function that cannot unwind"

Missing output example

As an example, here's the post-stack-trace output when testing #105632 with an older build:

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.68.0-nightly (657eefe2d 2022-12-11) running on x86_64-apple-darwin

query stack during panic:
#0 [typeck] type-checking `bar`
#1 [typeck_item_bodies] type-checking all item bodies
#2 [analysis] running analysis passes on this crate
end of query stack

Regression

Seems to be a regression from bdb07a8 (#103647) (@lqd)

Version

rustc 1.68.0-nightly (bdb07a8ec 2022-12-11)
binary: rustc
commit-hash: bdb07a8ec8e77aa10fb84fae1d4ff71c21180bb4
commit-date: 2022-12-11
host: x86_64-apple-darwin
release: 1.68.0-nightly
LLVM version: 15.0.6

[jruderman]

Requesting prioritization because affects the quality of bug reports and may interfere with bisection.

@rustbot prioritize

[compiler-errors]

@jruderman do you test on an x86_64 mac? otherwise, I'm curious how you bisected this to #103647.

[jruderman]

Yes, this is all on x86_64 mac.

[lqd]

I'm not sure why this would affect ICEs so I've posted the #105646 revert to allow time for some investigation.

[lqd]

This issue isn't platform-specific, and happens on all nightlies built with ThinLTO:

• on x64 mac, via Enable ThinLTO for rustc on x86_64-apple-darwin #103647 starting with nightly-2022-12-12 (being reverted in Revert "enable ThinLTO for rustc on x86_64-apple-darwin dist builds" #105646)
• on x64 msvc, via Enable ThinLTO for rustc on x64 msvc #103591 starting with the same nightly-2022-12-12
• on x64 linux, via Enable LTO for rustc_driver.so #101403 starting with nightly-2022-10-24, and which lands on stable 1.66 in 2 days.

Examples:

1. On the most recent nightlies, where ThinLTO is enabled on the main targets above: ICE with mismatch in trait associated constant #105632 linked in the OP

#![feature(associated_const_equality)]
#![allow(dead_code)]

trait TraitWAssocConst {
        const A: usize;
}

fn foo<T: TraitWAssocConst<A = 1>>() {}

fn bar<T: TraitWAssocConst<A = 0>>() {
        foo::<T>();
}

fn main() {}

And we can see on the playground that the usual ICE post-trace output is missing.

Note that this ICE was not present on nightly-2022-10-24, and is most useful for bisecting on win/mac, not linux: the following example should be usable for that.

2. An ICE whose existence crosses the Enable LTO for rustc_driver.so #101403 linux merge date, so you can see the before and after changes (this ICE happens in 1.66 and is fixed in 1.67): ICE: assertion failed: elem.index() < self.domain_size #103748

struct Apple((Apple, Option(Banana ? Citron)));

fn main() {}

We can see the ICE is missing the post trace output on the current beta (1.66.beta.2) on the playground, and the output changed in nightly-2022-10-24, it is present in nightly-2022-10-23.

---

Since this is useful output for reporting issues, debugging and bisection, should we do something about ThinLTO landing on stable on linux in 2 days (e.g. disabling rust.lto=thin on the x64 linux dist builder on beta) ? I'm not sure anyone will have the time to investigate and land a fix by then.

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-critical

[lqd]

#105800 should fix the -Zdylib-lto bug causing this issue, so we shouldn't need to revert the rust.lto = thin config on the dist builders.

[Noratrieb]

Can this be closed now?

[lqd]

Probably. The fix has landed on nightly and beta, but the PR is still stable-nominated. It's not really critical to do such a backport unless someone experiences issues on 1.66 or the triage WG sees too many bug reports they don't like.

[apiraino]

As @lqd says - the stable backport was discussed but ultimately kept "on hold" to see how the patch behaves in the beta channel. A stable backport sometimes means a point release and that's up to T-infra to decide.

Ok if you prefer to close this issue, we can always re-open if a stable backport will be approved (that will be discussed probably next week)

[jyn514]

This is several months old at this point, I think it's safe to say there won't be a stable backport 😄