-
Notifications
You must be signed in to change notification settings - Fork 13k
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
thread 'rustc' panicked at 'expression with never type wound up being adjusted' #96335
Comments
searched nightlies: from nightly-2022-04-01 to nightly-2022-04-22 bisected with cargo-bisect-rustc v0.6.2Host triple: x86_64-unknown-linux-gnu cargo bisect-rustc --test-dir=. --start=2022-04-01 --end=2022-04-22 --regress ice --access github |
A |
I think this is still open and it looks like a fun problem to dig into. Please let me know if I should let someone else work on it though please! @rustbot claim |
I also found this issue in that version's nightly rustc. I consider that is a nontrival problem worth digging into. @rustbot |
@oli-obk @PeterWrighten @Badel2 I also wasn't able to reduce the minimal error case much beyond what Badel2 posted. Do you happen to have a simpler error case, Peter? |
@PrestonFrom I'm assigned to your PR, and looked into this issue really quickly. So this is due to the new argument type compatibility algorithm implemented in #92364 (cc: @jackh726). The This is somewhat problematic, since this means that typeck code deeper in the stack attemps to apply adjustments twice and sometimes panicks because of this. A similar bug was fixed in #94596 when other diagnostic code called Since this will only reasonably happen during diagnostic code, I think it's fine for now to delay a bug. |
@compiler-errors Thank you for the background! That helps a lot to clarify things. I clearly need to do a lot more reading. |
Yeah, I also just have a simple ICE from rustc. But there has been some expositions from @compiler-errors , so I think maybe this issue would be solved in the future. |
…-errors delay bug when adjusting `NeverToAny` twice during diagnostic code Addresses Issue 96335 (rust-lang#96335) by using `delay_span_bug` instead of an assert and returning an error type from `check_expr_meets_expectation_or_error`. Fixes rust-lang#96335
…-errors delay bug when adjusting `NeverToAny` twice during diagnostic code Addresses Issue 96335 (rust-lang#96335) by using `delay_span_bug` instead of an assert and returning an error type from `check_expr_meets_expectation_or_error`. Fixes rust-lang#96335
…-errors delay bug when adjusting `NeverToAny` twice during diagnostic code Addresses Issue 96335 (rust-lang#96335) by using `delay_span_bug` instead of an assert and returning an error type from `check_expr_meets_expectation_or_error`. Fixes rust-lang#96335
…-errors delay bug when adjusting `NeverToAny` twice during diagnostic code Addresses Issue 96335 (rust-lang#96335) by using `delay_span_bug` instead of an assert and returning an error type from `check_expr_meets_expectation_or_error`. Fixes rust-lang#96335
I'm seeing an internal compiler error on the following input, found by fuzz-rustc:
Code
Error output
The ICE happens after reporting some other errors, so I guess low priority. Affected versions: nightly 2022-04-22 does show the ICE, but beta 1.61.0-beta.3 does not show the ICE.
Backtrace
The text was updated successfully, but these errors were encountered: