Merge subtree update for toolchain nightly-2025-11-25#530
Merged
Conversation
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#146573 (Constify Range functions) - rust-lang#146699 (Add `is_ascii` function optimized for LoongArch64 for [u8]) - rust-lang#148026 (std: don't leak the thread closure if destroying the thread attributes fails) - rust-lang#148135 (Ignore unix socket related tests for VxWorks) - rust-lang#148211 (clippy fixes and code simplification) - rust-lang#148395 (Generalize branch references) - rust-lang#148405 (Fix suggestion when there were a colon already in generics) r? `@ghost` `@rustbot` modify labels: rollup
…s, r=jhpratt add SliceIndex wrapper types Last and Clamp<Idx> Tracking issue: rust-lang#146179
…uarantees, r=scottmcm Make explicit that `TypeId`'s layout and size are unstable Or worded differently, explicitly remark non-stable-guarantee of `TypeId` layout and size. This PR makes no *additional* guarantees or non-guarantees, it only emphasizes that `TypeId`'s size and layout are unstable like any other `#[repr(Rust)]` types. This was discussed during [#t-compiler/meetings > [weekly] 2025-10-30 @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202025-10-30/near/547949347), where the compiler team discussed a request rust-lang#148265 to have the standard library (and language) commit to `TypeId` guaranteeing a size upper bound of 16 bytes. In the meeting, the consensus was: - We were sympathetic to the use case discussed in the request PR, however we feel like this stability guarantee is premature, given that there are unresolved questions surrounding the intended purpose of `TypeId`, and concerns surrounding its collision-resistance properties rust-lang#10389 and rust-lang#129014. We would prefer not making any of such guarantee until the collision-resistance concerns are resolved. - Committing to a stability guarantee on the size upper bound now would close the door to making `TypeId` larger (even if unlikely for perf reasons). Given that we have previously broken people who asserted the size of `TypeId` is 8 bytes, it was also discussed in the meeting that we should *explicitly* note that the size and layout of `TypeId` is not a stable guarantee, and is subject to changes between Rust releases, and thus cannot be relied upon -- if breakage in people's code is due to that assumption, it will be considered a won't-fix. - So even if `#[repr(Rust)]` types have unstable size and layout, this PR makes it explicit for `TypeId` since this type can feel "special" and users can be lead into thinking its size and layout is something they can rely upon. r? `@scottmcm` (or libs/libs-api/lang)
…r=sayantn stdarch subtree update Subtree update of `stdarch` to rust-lang/stdarch@b5c1645. Created using https://github.com/rust-lang/josh-sync. r? `@sayantn` --- Only the last 2 commits contain manual changes to some incorrect miri tests. The remainder is mechanical, and just synchronizes changes from stdarch.
This PR reverts RUST-147622 for several reasons: 1. The RUST-147622 PR would format the generated core library code using an arbitrary `rustfmt` picked up from `PATH`, which will cause hard-to-debug failures when the `rustfmt` used to format the generated unicode data code versus the `rustfmt` used to format the in-tree library code. 2. Previously, the `unicode-table-generator` tests were not run under CI as part of `coretests`, and since for `x86_64-gnu-aux` job we run library `coretests` with `miri`, the generated tests unfortunately caused an unacceptably large Merge CI time regression from ~2 hours to ~3.5 hours, making it the slowest Merge CI job (and thus the new bottleneck). 3. This PR also has an unintended effect of causing a diagnostic regression (RUST-148387), though that's mostly an edge case not properly handled by `rustc` diagnostics. Given that these are three distinct causes with non-trivial fixes, I'm proposing to revert this PR to return us to baseline. This is not prejudice against relanding the changes with these issues addressed, but to alleviate time pressure to address these non-trivial issues.
Fix documentation for std::panic::update_hook The equivalent code given in the documentation of `std::panic::update_hook`[^1] does not compile: * `set_hook` expects a boxed function * Missing closing delimiter for the closure [^1]: rust-lang#92649
…llaumeGomez Rollup of 8 pull requests Successful merges: - rust-lang#135099 (Add FileCheck annotations to mir-opt/copy-prop) - rust-lang#145903 (Give correct suggestion for a typo in raw pointers) - rust-lang#147520 (Port the remaining SIMD intrinsics to const-eval) - rust-lang#148068 (rustdoc: Use configured target modifiers when collecting doctests) - rust-lang#148099 (Prepare to move debugger discovery from compiletest to bootstrap) - rust-lang#148268 (rustdoc: fix `--emit=dep-info` on scraped examples) - rust-lang#148306 (Remove double check when decoding ExpnId to avoid races) - rust-lang#148378 (Fix documentation for std::panic::update_hook) r? `@ghost` `@rustbot` modify labels: rollup
Forward `TEST_SAMPLE_INTRINSICS_PERCENTAGE`
Add intrinsics for the new AMX target features
…, r=dtolnay Stabilize `fmt::from_fn` Resolves rust-lang#146705, pending its FCP. As discussed in that tracking issue and rust-lang#117729, this splits `fmt::from_fn` out from the `debug_closure_helpers` feature.
feat: add `from_fn_ptr` to `Waker` and `LocalWaker` Closes: rust-lang#146055
library: std: sys: net: uefi: tcp: Implement write_vectored - A working vectored write implementation for TCP4. - Also introduces a small helper UefiBox intended to be used with heap allocated UEFI DSTs. - Tested on OVMF cc ```@nicholasbishop```
…jorn3
Add alignment parameter to `simd_masked_{load,store}`
This PR adds an alignment parameter in `simd_masked_load` and `simd_masked_store`, in the form of a const-generic enum `core::intrinsics::simd::SimdAlign`. This represents the alignment of the `ptr` argument in these intrinsics as follows
- `SimdAlign::Unaligned` - `ptr` is unaligned/1-byte aligned
- `SimdAlign::Element` - `ptr` is aligned to the element type of the SIMD vector (default behavior in the old signature)
- `SimdAlign::Vector` - `ptr` is aligned to the SIMD vector type
The main motive for this is stdarch - most vector loads are either fully aligned (to the vector size) or unaligned (byte-aligned), so the previous signature doesn't cut it.
Now, stdarch will mostly use `SimdAlign::Unaligned` and `SimdAlign::Vector`, whereas portable-simd will use `SimdAlign::Element`.
- [x] `cg_llvm`
- [x] `cg_clif`
- [x] `miri`/`const_eval`
## Alternatives
Using a const-generic/"const" `u32` parameter as alignment (and we error during codegen if this argument is not a power of two). This, although more flexible than this, has a few drawbacks
- If we use an const-generic argument, then portable-simd somehow needs to pass `align_of::<T>()` as the alignment, which isn't possible without GCE
- "const" function parameters are just an ugly hack, and a pain to deal with in non-LLVM backends
We can remedy the problem with the const-generic `u32` parameter by adding a special rule for the element alignment case (e.g. `0` can mean "use the alignment of the element type), but I feel like this is not as expressive as the enum approach, although I am open to suggestions
cc `@workingjubilee` `@RalfJung` `@BoxyUwU`
…ngjubilee Implement Path::is_empty This implements `Path::is_empty` which is simply a convenience wrapper for `path.as_os_str().is_empty()`. Tracking issue: rust-lang#148494 ACP: rust-lang/libs-team#687
This adds to the existing proxy impl for &T.
Remove no longer necessary lint allow
…now_with_50_percent_more_mut, r=Amanieu
Merge `Vec::push{,_mut}_within_capacity`
Implements rust-lang/libs-team#689.
cc rust-lang#135974, rust-lang#100486
r? libs-api
…rue, r=Amanieu std-detect: improve detect macro docs Specifically, document that the detect macros expand to `true` when the feature is statically enabled. Now that we have a bunch of these macros, perhaps we should streamline further how they are documented? r? ``@Amanieu``
Member
|
@nilehmann It looks like Flux requires a toolchain update. @rafaelsamenezes ESBMC segfaults, could you please take a look? |
|
This may take us longer than usual, so please go ahead and merge if we don't have the fix soon enough. |
|
I created #533 to fix the VeriFast proof of RawVec. |
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.
|
I created #535 to fix flux. |
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.
I will take a look today |
|
@tautschnig it should be running fine now. |
feliperodri
approved these changes
Feb 2, 2026
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
There was a problem hiding this comment.
CodeQL found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.
This was referenced Jul 19, 2026
The Kani version this PR moves to (d4df833c8) is pinned to toolchain nightly-2025-11-25, which includes rust-lang#145513: deref temporaries are no longer assigned via `Rvalue::CopyForDeref` in runtime MIR. Kani's loop-contract instrumentation relies on that rvalue kind to recognize such temporaries in `for` loops whose pattern destructures the iterator element through a reference, like the for (i, &p5) in pow5.iter().enumerate().take(pow5_b - pow5_a) loop in number_of_digits_decimal_left_shift, and now emits spurious dereference failures for them, which failed the check_left_shift and check_number_of_digits_decimal_left_shift harnesses in CI: Failed Checks: dereference failure: pointer NULL File: "library/core/src/num/dec2flt/decimal_seq.rs", line 398 Reported as model-checking/kani#4658, fix proposed in model-checking/kani#4659. Until that fix is part of the pinned Kani version, disable the loop invariant on this loop and bound the two affected harnesses with #[kani::unwind(44)] instead: the loop runs at most pow5_b - pow5_a <= 42 iterations for the reachable TABLE entries, and the unwinding assertion proves that bound. Verified locally with the pinned Kani commit: all four decimal_seq harnesses pass (check_number_of_digits_decimal_left_shift 198s, check_left_shift 250s, check_round + check_right_shift 4s), which is slower than the loop-contract proofs (~20s each) but well within CI budgets. Co-authored-by: Kiro <kiro-agent@users.noreply.github.com>
The subtree sync brings in the new unstable exact_bitshifts feature (rust-lang#144336), adding unchecked_shl_exact and unchecked_shr_exact for all integer types. These match the --include-pattern "num::<impl.$ty>::unchecked_sh" patterns the autoharness CI jobs use for the existing unchecked_shl and unchecked_shr functions, so Kani now attempts to verify them against all possible inputs. Unlike their non-_exact siblings they carry no contracts, so autoharness rightfully reported their safety preconditions as violated ("attempt to shift by excessive shift distance"), failing all four autoharness CI jobs with 24 failures (12 integer types x {shl,shr}). Equip them with #[requires] contracts mirroring their assert_unsafe_precondition! conditions, exactly like unchecked_shl and unchecked_shr. Verified locally with the pinned Kani commit for u8 and i8 (the other types are the same macro expansion): all of unchecked_sh{l,r} and unchecked_sh{l,r}_exact verify successfully. Co-authored-by: Kiro <kiro-agent@users.noreply.github.com>
tautschnig
approved these changes
Jul 19, 2026
tautschnig
enabled auto-merge
July 19, 2026 20:16
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is an automated PR to merge library subtree updates from 2025-10-09 (rust-lang/rust@b6f0945) to 2025-11-25 (rust-lang/rust@c871d09) (inclusive) into main.
git mergeresulted in conflicts, which require manual resolution. Files were commited with merge conflict markers. Do not remove or edit the following annotations:git-subtree-dir: library
git-subtree-split: e3e34e0