Merge subtree update for toolchain nightly-2025-06-03

[github-actions]

This is an automated PR to merge library subtree updates from 2025-06-02 (rust-lang/rust@99e7c15) to 2025-06-03 (rust-lang/rust@5d707b0), inclusive. This is a clean merge, no conflicts were detected. Do not remove or edit the following annotations:
git-subtree-dir: library
git-subtree-split: 018adbd

[tautschnig]

Requires #386 to be merged first.

[carolynzech]

The check_is_ascii harness is failing:

2025-06-10T00:29:47.6611531Z  ** 2 of 97 failed (95 undetermined)
2025-06-10T00:29:47.6612227Z Failed Checks: unwinding assertion loop 0
2025-06-10T00:29:47.6613063Z  File: "/home/runner/work/verify-rust-std/verify-rust-std/head/library/core/src/slice/ascii.rs", line 489, in slice::ascii::is_ascii
2025-06-10T00:29:47.6613834Z Failed Checks: unwinding assertion loop 2
2025-06-10T00:29:47.6614572Z  File: "/home/runner/work/verify-rust-std/verify-rust-std/head/library/core/src/slice/ascii.rs", line 502, in slice::ascii::is_ascii
2025-06-10T00:29:47.6615208Z 
2025-06-10T00:29:47.6615310Z VERIFICATION:- FAILED
2025-06-10T00:29:47.6615691Z [Kani] info: Verification output shows one or more unwinding failures.
2025-06-10T00:29:47.6616315Z [Kani] tip: Consider increasing the unwinding value or disabling `--unwinding-assertions`.
2025-06-10T00:29:47.6616842Z Verification Time: 3.6555307s
2025-06-10T00:29:47.6620172Z 

I suspect because the newest Kani version enables the sse2 target feature for x86 architectures, which means that we look at this version of is_ascii:

verify-rust-std/library/core/src/slice/ascii.rs

Lines 470 to 472 in 0840b22

	#[cfg(all(target_arch = "x86_64", target_feature = "sse2"))]
	#[inline]
	const fn is_ascii(bytes: &[u8]) -> bool {

instead of this one, where the loop invariant is:

verify-rust-std/library/core/src/slice/ascii.rs

Lines 363 to 366 in 0840b22

	#[cfg(not(all(target_arch = "x86_64", target_feature = "sse2")))]
	#[inline]
	#[rustc_allow_const_fn_unstable(const_eval_select)] // fallback impl has same behavior
	const fn is_ascii(s: &[u8]) -> bool {

@thanhnguyen-aws can you add a loop invariant to the other function so that the proof passes again?

[carolynzech]

Re: disabling ./x test. We were getting a duplicate lang item error. I suspect that it's caused by rust-lang#119899, which implements a stage 0 bootstrap redesign.

The blog post describing this change suggests:

The minimum stage to check, build and test the standard library is now stage 1. ./x {check,build,test} library --stage=0 are now no-ops; switch to --stage 1 instead.

I did that, but that produces this new error:

error[E0514]: found crate `safety` compiled by an incompatible version of rustc
    --> library/core/src/ptr/mod.rs:2090:3
     |
2090 | #[safety::requires(ub_checks::can_dereference(src))]
     |   ^^^^^^
     |
     = note: the following crate versions were found:
             crate `safety` compiled by rustc 1.88.0-beta.4 (95597e848 2025-05-25): /private/var/folders/2r/g_zkltvs27d511hds3r2_rsw0000gq/T/check_rustc_XXXXXX.7FYUACIWO7/build/aarch64-apple-darwin/stage1-std/release/deps/libsafety-59a79aebc2fdb0fb.dylib
     = help: please recompile that crate using this compiler (rustc 1.89.0-nightly (5d707b07e 2025-06-02)) (consider running `cargo clean` first)

For more information about this error, try `rustc --explain E0514`.
error: could not compile `core` (lib) due to 45 previous errors

(The cargo clean suggestion doesn't work, I tried).

This error doesn't make sense to me--if I'm understanding the change correctly, the bootstrap sequence should only build the standard library with the stage1 nightly compiler, so I don't understand how a version of this crate compiled with the stage0 beta compiler would be hanging around. I think there's two possibilities here:

1. There's a bug in the new bootstrap sequence where it can't handle the case where the local standard library adds a new crate, or
2. I'm misunderstanding something here and we just need to change something on our end to fix it

For the sake of unblocking this upgrade sooner rather than later, I'm inclined to just turn ./x test off for now. It seems like they're still doing quite a bit of work upstream on this feature (e.g. rust-lang#141914), so if the issue is on their end, I wouldn't be surprised if it gets fixed without us doing anything. I can keep retrying it periodically to see if it gets fixed, and if it doesn't, I can go on Zulip and ask for some help.

[tautschnig]

Looks like the loop invariant still needs work for we appear to require a modifies clause:

Failed Checks: Check assigns clause inclusion for loop slice::ascii::is_ascii.0