Miri subtree update

[RalfJung]

r? @ghost

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[RalfJung]

@bors r+ p=1

[bors]

📌 Commit 38847ae has been approved by RalfJung

It is now in the queue for this repository.

[RalfJung]

@bors r-

[RalfJung]

Very strange...

 +error: Undefined Behavior: calling a function with ABI system using caller ABI C
+ --> $DIR/windows_join_multiple.rs:LL:CC
+ |
+LL | assert_eq!(WaitForSingleObject(blocker, INFINITE), WAIT_OBJECT_0);
+ | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ calling a function with ABI system using caller ABI C

Likely caused by rust-lang/miri#3239. @beepster4096 any idea why this would pass on Miri CI but now fail here? Did the windows crate recently change which ABI it uses for these functions? But even then, our test suite should be using pinned versions...

[RalfJung]

Hm, there do seem to be some conditions under which these functions get a different ABI? Specifically, #[cfg(all(windows_raw_dylib, not(target_arch = "x86")))]. x86-64 is not x86. I can't quite figure out where windows_raw_dylib comes from.

But it seems just plain wrong to have this sometimes be a "C" function and sometimes a "system" function?

[RalfJung]

I guess the Miri build is somehow picking up this:

rust/src/bootstrap/src/core/builder.rs

Lines 1435 to 1441 in c350d3c

	// By default, windows-rs depends on a native library that doesn't get copied into the
	// sysroot. Passing this cfg enables raw-dylib support instead, which makes the native
	// library unnecessary. This can be removed when windows-rs enables raw-dylib
	// unconditionally.
	ifletMode::Rustc | Mode::ToolRustc = mode {
	rustflags.arg("--cfg=windows_raw_dylib");
	}

[RalfJung]

I think I have found a work-around; @oli-obk please have a look.

But it'd also be good if someone could look into why windows-rs uses a different ABI for the same function depending on this --cfg windows_raw_dylib flag, that seems suspicious (and there's no comment explaining why this happens).

EDIT: I found out why it happens: to work around other things (#110505). What a chain of unfortunateness.

[oli-obk]

@bors r+

[bors]

📌 Commit 5aa15b6 has been approved by oli-obk

It is now in the queue for this repository.

[oli-obk]

This seems generally good to me. We should mostly isolate tests from their environment