-
Notifications
You must be signed in to change notification settings - Fork 13.3k
ICE in uv
when doing a rebuild after code change
#125367
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
A-incr-comp
Area: Incremental compilation
C-bug
Category: This is a bug.
E-needs-mcve
Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
Finally, an incr-comp ICE with a repro <3 |
A repro with no external deps:
pub trait P {
type A;
}
struct S;
impl P for S {
type A = C;
}
struct T<D: P>(D::A, Z<D>);
struct Z<D: P>(D::A, String);
impl<D: P> T<D> {
pub fn i() -> Self {
loop {}
}
}
enum C {
E(()),
}
pub fn m() {
T::<S>::i();
} |
rustc 1.80.0-nightly (c987ad5 2024-05-01) still crashes |
duplicate of #107226 ? |
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this issue
Jun 21, 2024
Trying to address an incremental compilation issues This pull request contains two independent changes, one makes it so when `try_force_from_dep_node` fails to recover a query - it marks the node as "red" instead of "green" and the second one makes Debug impl for `DepNode` less panicky if it encounters something from the previous compilation that doesn't map to anything in the current one. I'm not 100% confident that this is the correct approach, but so far I managed to find a bunch of comments suggesting that some things are allowed to fail in a certain way and changes I made are allowing for those things to fail this way and it fixes all the small reproducers I managed to find. Compilation panic this pull request avoids is caused by an automatically generated code on an associated type and it is not happening if something else marks it as outdated first (or close like that, but scenario is quite obscure). Fixes rust-lang/rust#107226 Fixes rust-lang/rust#125367
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-incr-comp
Area: Incremental compilation
C-bug
Category: This is a bug.
E-needs-mcve
Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Code
Unfortunately this is nowhere near a minimal example, but it was a tricky one to figure out how to reliably reproduce. Here are the steps:
Meta
Error output
This also happens with current nightly too:
And here's the error from nightly:
Unfortunately it's hard to say which version of Rust introduced this error since
uv
tracks the latest stable version of Rust.One possible way to narrow this down is that not all changes to the code seem to provoke the ICE. For example, if you checkout
223980e4bc22ec17b4d79b8e5f3f00b38c144c1a
, docargo b -p uv
and then checkout44fe0f6749249a223646baa87f9d7ce40b2e40f3
and build that too, then it works fine. So I wonder if there is something about astral-sh/uv@eac8221 that is provoking the problem.The text was updated successfully, but these errors were encountered: