Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
makes this somewhat tricky, Miri will have to support more ways of using . (It supported enough for the thread parker implementation, but now it seems we are using more of that API.)
We support FUTEXWAIT and FUTEXWAKE, but not FUTEXWAITBITSET. what would you say is a good place to learn about futex semantics, ideally suitable as a reference documentation that one can follow if one wants to do a reimplementation in an interpreter?
The man page for the Linux syscall is the best documentation/reference: FUTEXWAITBITSET shouldn't be hard to implement. I can work on Miri support for it. :)
That would be great. :) Best to start with (rather than the usual ) as otherwise you will have to also deal with other breakage that happened after the futex change.
This adds support for FUTEXWAITBITSET and FUTEXWAKEBITSET in Miri:
The next trouble is -- somehow this broke printing to stdout in Miri on Windows targets, which now just loops infinitely. any idea what might be going on?
I made a quick summary in but still need to investigate properly. Short version is that in some cases we're passing asynchronous handles to child processes, which is unsound when read synchronously (but mostly seemed to work in practice). Though I'm not actually sure why that should make it loop infinitely since it's calling ?
Note that this happens even on a Linux host interpreting Windows target MIR. So it might be a different problem?
The odd thing is, these tests do not even read/write a file (Miri does not support that on Windows targets). They just write to stderr/stdout. If NtRead/WriteFile were ever executed, Miri would stop immediately since it does not support those operations.
Oh right! Hm... I'm not really sure why that be. The changes are limited to reading and writing from a handle.
I had another look and as far I can tell there's no code path that doesn't call either or . The only thing of note it does before that is call . Just to be clear, you're totally certain it was that PR that caused the issue?
Yeah I bisected it to this PR in (I can double-check later.)
Then I'll admit to being stumped.
Does the Windows stdout/stderr go through a "handle" or is it a separate code path?
Ah, I did recently change piped stdout/stderr to use a loop (in ). But it also uses new functions to do that ( and ).
But Miri works fine on which includes that PR...
Oh, I think it's pretty simple -- is declared via , and in Miri that function is just not available. Then what happens is that it panics, which triggers printing to stderr, so it tries calling again, and the loop continues. It doesn't make a lot of sense for to be a when the "fallback" branch consists in an infinite loop on any write to stdout/stderr...
Oh! Sorry! I did that without even thinking and it didn't even occur to me look at that again. The fallback should probably just abort or return an error. I'll make a PR.
Uff, that compat stuff is using some nasty things which Miri would all have to support. :/ Is there any chance these functions could be called like regular 'extern fn', without all that compat craziness? I doubt we are making stdin/stdout optional so for all intents and purposes those functions have to exist for Rust programs to run on Windows.
The problem is these functions really should be loaded at runtime. I guess we could technically do it at load time but we'd at least need to wait until the feature is stabilized because we can't necessarily count on users having the right import library.
An alternative might be a hack like this: Unfortunately I don't have the time to implement wild linker stuff in Miri for a platform that Miri only barely supports anyway...
Miri CI finally passes again. :tada: This took a lot more time than I actually have, so I think next time Windows breaks in obscure ways I will have to just disable the tests for that platform and hope someone else can maintain that code.

Discussion:
<del> Subproject commit 732461b4cd2c4bfd8b229ad43fbc32c193b4049d </del> <ins> Subproject commit be72564a643758afcc1de152ead2359d489149c0 </ins>