ICE when returning value bound by if let ... && let ...
#99852
Comments
H2WO4
added
C-bug
|
cc @c410-f3r |
|
Code does not compile. Here goes a local attempt that was OK. use core::convert::Infallible;
fn lambda<U>() -> U
where
U: Default
{
let foo: Result<i32, ()> = Ok(1);
let baz: U = <_>::default();
if let Ok(foo) = foo && let Ok(bar) = transform(foo) {
bar
} else {
baz
}
}
fn transform<T, U>(_: T) -> Result<U, Infallible> {
todo!()
}IFAICT, |
|
@H2WO4 would it be possible to upload a self contained example that reproduces the issue? |
|
It seams that the ICE only occurs with |
|
This panics for me: fn lambda<T, U>() -> U
where T: Default,
U: Default
{
let foo: Result<T, ()> = Ok(T::default());
let baz: U = U::default();
if let Ok(foo) = foo && let Ok(bar) = transform(foo) {
bar
} else {
baz
}
}
fn transform<T, U>(input: T) -> Result<U, ()> {
todo!()
}But removing the generic fn lambda<T>() -> u32
where T: Default
{
let foo: Result<T, ()> = Ok(T::default());
let baz: u32 = 0;
if let Ok(foo) = foo && let Ok(bar) = transform(foo) {
bar
} else {
baz
}
}
fn transform<T, U>(input: T) -> Result<U, ()> {
todo!()
} |
|
Additionally, it still panics if we remove the generic fn lambda<U>() -> U
where U: Default
{
let foo: Result<i32, ()> = Ok(1);
let baz: U = U::default();
if let Ok(foo) = foo && let Ok(bar) = transform(foo) {
bar
} else {
baz
}
}
fn transform<T, U>(input: T) -> Result<U, ()> {
todo!()
} |
|
Minimized: fn lambda<T: Default>() -> T {
if true && let Some(bar) = transform() {
bar
} else {
T::default()
}
}
fn transform<T>() -> Option<T> {
None
} |
|
From my playground tests, all the above snippets only happen in optimized ***** libraries *****. I also couldn't reproduce locally using a slightly older compiler version (nightly-2022-07-15). |
|
OK, just updated the compiler and the ICE happened. Since I've only worked in the parser these past weeks, it is possible that some recent MIR change caused this current behaviour. |
|
searched nightlies: from nightly-2022-06-01 to nightly-2022-07-28 bisected with cargo-bisect-rustc v0.6.1Host triple: x86_64-unknown-linux-gnu cargo bisect-rustc --start 2022-06-01 --preserve --prompt -- build --release Another rollup.... But some of these are MIR related. |
|
From that list, #98930 seems to be the most likely cause (edit: note this is just a guess). |
|
I wonder if this has the same cause as #99866 .... Hmmm..... They're both broken MIR, but it's a different exact error. |
|
I think this is caused by #96856 as well. My local revert of it didn't ICE on the snippet, but nightly did (both compiled with |
|
While it seems to be caused by the same PR, they don't appear to be caused by the same underlying issue. |
|
@rustbot claim |
|
@rustbot release |
|
@rustbot release-assignment |
|
While investigating this, I found out about #100513, which is the underlying cause for this and other let_chains problems. The real fix here is to fix the desugaring. |
|
That PR just enabled validation that cought the broken mir, it has already been broken before. |
Hum, I see. Thanks! |
|
Oooppsss... Sorry, this test still ICE. Wasn't able to reproduce before but now it is known that the minimal compiler arguments are @H2WO4 Can you re-open? |
|
WG-prioritization assigning priority (Zulip discussion). @rustbot label -I-prioritize +P-high T-compiler |
…, r=davidtwco Add regression test for issue rust-lang#99938 That issue was a dupe of rust-lang#99852, and it got fixed since, but it's always better to have multiple regression tests rather than one. closes rust-lang#99938
…, r=davidtwco Add regression test for issue rust-lang#99938 That issue was a dupe of rust-lang#99852, and it got fixed since, but it's always better to have multiple regression tests rather than one. closes rust-lang#99938
…-obk Fix unwind drop glue for if-then scopes cc `@est31` Fix rust-lang#102317 Fix rust-lang#99852 This PR fixes the drop glue for unwinding from a panic originated in a drop while breaking out for the else block in an `if-then` scope. MIR validation does not fail for the synchronous versions of the test program, because `StorageDead` statements are skipped over in the unwinding process. It is only becoming a problem when it is inside a generator where `StorageDead` must be kept around.
Code
Meta
rustc --version --verbose:Error output
Backtrace
The text was updated successfully, but these errors were encountered: