-
Notifications
You must be signed in to change notification settings - Fork 349
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: Failed to normalize <[closure] as std::ops::FnOnce<(&S,)>>::Output #2433
Comments
Uh, no idea... all that normalization stuff is a black box to me.^^ "Failed to normalize <[closure@src/main.rs:24:19: 24:22] as std::ops::FnOnce<(&S,)>>::Output" is odd, if it knows the closure type it should be able to just figure out the output type? @oli-obk any idea? |
if this is a recent regression, it could be due to rust-lang/rust#99383 Though... in |
Yeah, with the 2022-07-19 nightly there seems to be no ICE. |
@ouz-a reports the problem remains after reverting their PR. OTOH I have confirmed that the problem definitely started with this rollup: rust-lang/rust#99506. |
Uh... so with 3c3c5da9adfdf308b5189b8034c07e0dc5492a54 I get a different error, somehow?
@ouz-a which error did you get after reverting, was it just some ICE or exactly the ICE that @matthiaskrgr reported? |
Okay so this is fascinating. With just the first two PRs of the rollup, I get the above ICE. That is almost certainly rust-lang/rust#99345 (since the only other PR included yet is something about Apple Watch). When I also include rust-lang/rust#99383, I get the ICE @matthiaskrgr reports. |
Yeah I think we are actually seeing 2 ICEs in one example. If I merge either rust-lang/rust#99345 or rust-lang/rust#99383, I get an ICE. |
@RalfJung how does one reproduce this error? I don't know how to pass a UI test to a locally built Miri. |
For the record, I checked out rust-lang/rust@d60d88f, which is bors merge commit directly prior to the rollup mentioned in this issue. The ICE that was mentioned in this comment reproduces on that commit as well. (at least, I think I tested it correctly...) Note that it's a debug assertion in The ICE that @matthiaskrgr reported at the beginning of this issue is almost certainly due to rust-lang/rust#99383, and the debug assertion that is seen when one tries to reproduce it locally by checking out a commit in the repo and building locally is probably unrelated. It's probably worthwhile to investigate both. I know opaques pretty well and I might spend some time looking at it tonight. |
After checking out this repo, you can do
to run a file with a
Strange, I did the same and couldn't reproduce. But it is also possible I made a mistake, between my too-many-checkouts, so I'll try again. |
Oh, good point. When I tried to reproduce I did that with a release build, later when I tested the individual parts of the rollup I used a local rustc build with debug assertions. So rust-lang/rust#99345 is probably innocent, sorry for the noise.
Yeah... also that debug assertion means when one uses a local build to try and fix the problem (e.g. by reverting rust-lang/rust#99383, as a first test), one still gets an ICE.
That would be great. :) I am at a complete loss here, I don't know this stuff at all. |
By applying @bjorn3 's suggestion to turn |
This is due to rust-lang/rust@a84e3fa. Removing that causes this ICE to go away on master. Might be worth revisiting rust-lang/rust#89285 and formulating a better fix. |
I submitted that as rust-lang/rust#100918. But we cannot really add this as a test if it still fails with debug assertions enabled; that would break any time I do |
add regression test for miri issue 2433 Adding this here because the test needs to be run with debug assertions enabled to be sure so I had to run it in the rustc workspace. Cc rust-lang/miri#2433 r? `@oli-obk`
add regression test for miri issue 2433 Adding this here because the test needs to be run with debug assertions enabled to be sure so I had to run it in the rustc workspace. Cc rust-lang/miri#2433 r? `@oli-obk`
add regression test for miri issue 2433 Adding this here because the test needs to be run with debug assertions enabled to be sure so I had to run it in the rustc workspace. Cc rust-lang/miri#2433 r? ``@oli-obk``
add regression test for miri issue 2433 Adding this here because the test needs to be run with debug assertions enabled to be sure so I had to run it in the rustc workspace. Cc rust-lang#2433 r? ``@oli-obk``
add regression test for miri issue 2433 Adding this here because the test needs to be run with debug assertions enabled to be sure so I had to run it in the rustc workspace. Cc rust-lang#2433 r? ``@oli-obk``
This bug exists again now due to a revert, but it's a rustc bug so we track it at rust-lang/rust#104601. |
…_regions, r=oli-obk try_normalize_after_erasing_regions: promote an assertion to always run In rust-lang/miri#2433 this assertion has been seen to trigger, so it might be worth actually checking this? Regressing debug assertions are very easy to miss until much later, and then they become quite hard to debug.
… r=oli-obk try_normalize_after_erasing_regions: promote an assertion to always run In rust-lang#2433 this assertion has been seen to trigger, so it might be worth actually checking this? Regressing debug assertions are very easy to miss until much later, and then they become quite hard to debug.
code from rustc
./src/test/ui/type-alias-impl-trait/issue-72793.rs
This has been fixed on the rustc side, why does this crash with miri now? 🤔
The text was updated successfully, but these errors were encountered: