-
Notifications
You must be signed in to change notification settings - Fork 13.4k
miri
no longer builds after rust-lang/rust#101333
#101344
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Ah damn it, we keep getting broken so there's still no nightly with Miri. :( |
Building std now ICEs on windows...?
The same target works fine on my system, so it is host-specific. Sounds like one of the PRs in that rollup is buggy... |
@RalfJung do you have a stack trace for that ICE? |
Nope, I cannot reproduce so all we got is the log from CI. The ICE is here. |
Miri CI cannot reproduce either, not even in a Windows host. It's a 32bit host though. Would be great if someone with an x86_64 windows host could try to clone the Miri repo and do |
We're seeing a related-looking issue on Fuchsia on the same commit:
|
I'm unable to reproduce the ICE with
Btw the advice of |
This does look like my PR causes this. |
Yeah when I wrote that, the other PR had not landed yet. ;) |
Hm, that is odd. Not sure what the tools builder does differently, maybe it has debug assertions enabled? The line number in the ICE is so bad due to #100696. |
Not sure how related they really are, the original ICE is some kind of out-of-bounds slice access within rustc itself... |
on it |
Turns out the strange Windows-only ICE was caused by a buggy debug assertion: |
…ring, r=tmandry Normalize before erasing late-bound regions in `equal_up_to_regions` Normalize erasing regions **first**, before passing the type through a `BottomUpFolder` which erases late-bound regions too. The root cause of this issue is due to 96d4137, which removes a `normalize_erasing_regions` that happens before this call to `equal_up_to_regions`. While reverting that commit might be a fix, I think it was suspicious to be erasing late-bound regions first _then_ normalizing types in the first place in `equal_up_to_regions`. ----- I am tempted to ask the reviewer to review and `r+` this without a UI test, since the existing issues that I think this fixes are all incredibly difficult to minimize (anything hyper/warp related, given the nature of those libraries 😓) or impossible to reproduce locally (the miri test), namely: * This recently reported issue with tokio + warp: rust-lang#101430 * This issue from `@RalfJung` about Miri being broken: rust-lang#101344 * This additional issue reported in a comment by `@tmandry` (issue with fuchsia + hyper): rust-lang#101344 (comment) I have locally verified that the repro in rust-lang#101430 is fixed with this PR, but after a couple of hours of attempting to minimize this error and either failing to actually repro the ICE, or being overwhelmed with the number of traits and functions I need to inline into a UI test, I have basically given up. Thoughts are appreciated on how best to handle this. r? `@oli-obk` who is at the intersection of MIR and types-related stuff who may be able to give advice 😅
…mandry Normalize before erasing late-bound regions in `equal_up_to_regions` Normalize erasing regions **first**, before passing the type through a `BottomUpFolder` which erases late-bound regions too. The root cause of this issue is due to 96d4137deed6c52c6db2dd19568c37d1c160f1e7, which removes a `normalize_erasing_regions` that happens before this call to `equal_up_to_regions`. While reverting that commit might be a fix, I think it was suspicious to be erasing late-bound regions first _then_ normalizing types in the first place in `equal_up_to_regions`. ----- I am tempted to ask the reviewer to review and `r+` this without a UI test, since the existing issues that I think this fixes are all incredibly difficult to minimize (anything hyper/warp related, given the nature of those libraries 😓) or impossible to reproduce locally (the miri test), namely: * This recently reported issue with tokio + warp: #101430 * This issue from `@RalfJung` about Miri being broken: #101344 * This additional issue reported in a comment by `@tmandry` (issue with fuchsia + hyper): rust-lang/rust#101344 (comment) I have locally verified that the repro in #101430 is fixed with this PR, but after a couple of hours of attempting to minimize this error and either failing to actually repro the ICE, or being overwhelmed with the number of traits and functions I need to inline into a UI test, I have basically given up. Thoughts are appreciated on how best to handle this. r? `@oli-obk` who is at the intersection of MIR and types-related stuff who may be able to give advice 😅
…mandry Normalize before erasing late-bound regions in `equal_up_to_regions` Normalize erasing regions **first**, before passing the type through a `BottomUpFolder` which erases late-bound regions too. The root cause of this issue is due to 96d4137deed6c52c6db2dd19568c37d1c160f1e7, which removes a `normalize_erasing_regions` that happens before this call to `equal_up_to_regions`. While reverting that commit might be a fix, I think it was suspicious to be erasing late-bound regions first _then_ normalizing types in the first place in `equal_up_to_regions`. ----- I am tempted to ask the reviewer to review and `r+` this without a UI test, since the existing issues that I think this fixes are all incredibly difficult to minimize (anything hyper/warp related, given the nature of those libraries 😓) or impossible to reproduce locally (the miri test), namely: * This recently reported issue with tokio + warp: #101430 * This issue from `@RalfJung` about Miri being broken: #101344 * This additional issue reported in a comment by `@tmandry` (issue with fuchsia + hyper): rust-lang/rust#101344 (comment) I have locally verified that the repro in #101430 is fixed with this PR, but after a couple of hours of attempting to minimize this error and either failing to actually repro the ICE, or being overwhelmed with the number of traits and functions I need to inline into a UI test, I have basically given up. Thoughts are appreciated on how best to handle this. r? `@oli-obk` who is at the intersection of MIR and types-related stuff who may be able to give advice 😅
Hello, this is your friendly neighborhood mergebot.
After merging PR #101333, I observed that the tool miri has failing tests.
A follow-up PR to the repository https://github.com/rust-lang/miri is needed to fix the fallout.
cc @matthiaskrgr, do you think you would have time to do the follow-up work?
If so, that would be great!
The text was updated successfully, but these errors were encountered: