-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
ICE: panic adding warp::trace::request()
combinator
#108721
Comments
searched nightlies: from nightly-2023-02-01 to nightly-2023-03-04 bisected with cargo-bisect-rustc v0.6.5Host triple: x86_64-unknown-linux-gnu cargo bisect-rustc --start=2023-02-01 --regress=ice Regressed in #107688, cc @lukas-code @jackh726 |
I have (a couple of) fixes for this PR, but I really need this minimized :/ |
WG-prioritization assigning priority (Zulip discussion). @rustbot label -I-prioritize +P-critical +E-needs-mcve |
I'll work on minimizing it in the meantime |
I've started some work I https://github.com/Nilstrieb/icefun but it's extremely miserable because of hypers internal highly entangled generic mess |
I tried some more and I'm convinced that this ICE here cannot be minimized in a reasonable amount of time. The ICE is very brittle and disappears with seemingly random changes and the codebase is huge and highly generic with many bounds. |
Retry `pred_known_to_hold_modulo_regions` with fulfillment if ambiguous Fixes rust-lang#108721 The problem here is that when we're checking `is_sized_raw` during codegen on some type that has a lot of opaques in it, something emits several nested obligations that are individually ambiguous, but when processed together in a loop then apply modulo regions. Since the `evaluate_predicates_recursively` inner loop doesn't process predicates until they stop changing, we return `EvaluatedToAmbig`, which makes the sized check return false incorrectly. See: https://github.com/rust-lang/rust/blob/f15f0ea73972786e426732c5b92ba9a904b866c4/compiler/rustc_trait_selection/src/traits/select/mod.rs#L596-L606 ... Compared to the analogous loop in the new solver: https://github.com/rust-lang/rust/blob/f15f0ea73972786e426732c5b92ba9a904b866c4/compiler/rustc_trait_selection/src/solve/mod.rs#L481-L512 To fix this, if we get ambiguous during `pred_known_to_hold_modulo_regions`, just retry the obligation in a fulfillment context. -- Unfortunately... I don't have a test for this. I've only tested this locally. Pending minimization :/ r? types
Retry `pred_known_to_hold_modulo_regions` with fulfillment if ambiguous Fixes rust-lang#108721 The problem here is that when we're checking `is_sized_raw` during codegen on some type that has a lot of opaques in it, something emits several nested obligations that are individually ambiguous, but when processed together in a loop then apply modulo regions. Since the `evaluate_predicates_recursively` inner loop doesn't process predicates until they stop changing, we return `EvaluatedToAmbig`, which makes the sized check return false incorrectly. See: https://github.com/rust-lang/rust/blob/f15f0ea73972786e426732c5b92ba9a904b866c4/compiler/rustc_trait_selection/src/traits/select/mod.rs#L596-L606 ... Compared to the analogous loop in the new solver: https://github.com/rust-lang/rust/blob/f15f0ea73972786e426732c5b92ba9a904b866c4/compiler/rustc_trait_selection/src/solve/mod.rs#L481-L512 To fix this, if we get ambiguous during `pred_known_to_hold_modulo_regions`, just retry the obligation in a fulfillment context. -- Unfortunately... I don't have a test for this. I've only tested this locally. Pending minimization :/ r? types
Retry `pred_known_to_hold_modulo_regions` with fulfillment if ambiguous Fixes rust-lang#108721 The problem here is that when we're checking `is_sized_raw` during codegen on some type that has a lot of opaques in it, something emits several nested obligations that are individually ambiguous, but when processed together in a loop then apply modulo regions. Since the `evaluate_predicates_recursively` inner loop doesn't process predicates until they stop changing, we return `EvaluatedToAmbig`, which makes the sized check return false incorrectly. See: https://github.com/rust-lang/rust/blob/f15f0ea73972786e426732c5b92ba9a904b866c4/compiler/rustc_trait_selection/src/traits/select/mod.rs#L596-L606 ... Compared to the analogous loop in the new solver: https://github.com/rust-lang/rust/blob/f15f0ea73972786e426732c5b92ba9a904b866c4/compiler/rustc_trait_selection/src/solve/mod.rs#L481-L512 To fix this, if we get ambiguous during `pred_known_to_hold_modulo_regions`, just retry the obligation in a fulfillment context. -- Unfortunately... I don't have a test for this. I've only tested this locally. Pending minimization :/ r? types
Retry `pred_known_to_hold_modulo_regions` with fulfillment if ambiguous Fixes rust-lang#108721 The problem here is that when we're checking `is_sized_raw` during codegen on some type that has a lot of opaques in it, something emits several nested obligations that are individually ambiguous, but when processed together in a loop then apply modulo regions. Since the `evaluate_predicates_recursively` inner loop doesn't process predicates until they stop changing, we return `EvaluatedToAmbig`, which makes the sized check return false incorrectly. See: https://github.com/rust-lang/rust/blob/f15f0ea73972786e426732c5b92ba9a904b866c4/compiler/rustc_trait_selection/src/traits/select/mod.rs#L596-L606 ... Compared to the analogous loop in the new solver: https://github.com/rust-lang/rust/blob/f15f0ea73972786e426732c5b92ba9a904b866c4/compiler/rustc_trait_selection/src/solve/mod.rs#L481-L512 To fix this, if we get ambiguous during `pred_known_to_hold_modulo_regions`, just retry the obligation in a fulfillment context. -- Unfortunately... I don't have a test for this. I've only tested this locally. Pending minimization :/ r? types
We don't have a test, but given that we won't get a test from this report, keeping it open doesn't seem useful. |
* Now that <rust-lang/rust#108721> is landed on rust master, we can push the nightly version to bleeding edge again
…errors Restore `pred_known_to_hold_modulo_regions` As requested by `@lcnr` in rust-lang#123275 (comment) this PR restores `pred_known_to_hold_modulo_regions` to fix that "unexpected unsized tail" beta regression. This also adds the reduced repro from rust-lang#123275 (comment) as a sub-optimal test is better than no test at all, and it'll also cover rust-lang#108721. It still ICEs on master, even though https://github.com/phlip9/rustc-warp-ice doesn't on nightly anymore, since rust-lang#122493. Fixes rust-lang#123275. r? `@compiler-errors` but feel free to close if you'd rather have a better test instead cc `@wesleywiser` who had signed up to do the revert Will need a backport if we go with this PR: `@rustbot` label +beta-nominated
Rollup merge of rust-lang#123578 - lqd:regression-123275, r=compiler-errors Restore `pred_known_to_hold_modulo_regions` As requested by `@lcnr` in rust-lang#123275 (comment) this PR restores `pred_known_to_hold_modulo_regions` to fix that "unexpected unsized tail" beta regression. This also adds the reduced repro from rust-lang#123275 (comment) as a sub-optimal test is better than no test at all, and it'll also cover rust-lang#108721. It still ICEs on master, even though https://github.com/phlip9/rustc-warp-ice doesn't on nightly anymore, since rust-lang#122493. Fixes rust-lang#123275. r? `@compiler-errors` but feel free to close if you'd rather have a better test instead cc `@wesleywiser` who had signed up to do the revert Will need a backport if we go with this PR: `@rustbot` label +beta-nominated
* Now that <rust-lang/rust#108721> is landed on rust master, we can push the nightly version to bleeding edge again
Overview
While trying to upgrade rustc to the latest nightly, I stumbled across a Rust compiler panic. Here's a repo that contains a minimum-reproducible test case (well, reasonably compact): https://github.com/phlip9/rustc-warp-ice.
From my brief investigation, it appears that adding the
warp::trace::request()
combinator causes recent rustc nightly's to panic.I've bisected the recent nightly versions;
nightly-2023-02-09
is the first that starts panicking. Running withnightly-2023-02-08
builds successfully.To reproduce the bug, just run
cargo build
. Runningcargo check
doesn't panic, though, since it seems to be codegen related.Code
Meta
rustc --version --verbose
:Error output
Backtrace
The text was updated successfully, but these errors were encountered: