Merge subtree update for toolchain nightly-2026-02-05#613
Open
github-actions[bot] wants to merge 10000 commits into
Open
Merge subtree update for toolchain nightly-2026-02-05#613github-actions[bot] wants to merge 10000 commits into
github-actions[bot] wants to merge 10000 commits into
Conversation
remove multiple unhelpful `reason = "..."` values from `#[unstable(...)]` invocations
The vast majority of `#[unstable()]` attributes already has no explicit reason specified. This PR removes the `reason = "..."` value for the following unhelpful or meaningless reasons:
* "recently added"
* "new API"
* "recently redesigned"
* "unstable"
An example of how the message looks with and without a reason:
```rust
fn main() {
Vec::<()>::into_parts;
Vec::<()>::const_make_global;
}
```
```
error[E0658]: use of unstable library feature `box_vec_non_null`: new API
--> src/main.rs:2:5
|
2 | Vec::<()>::into_parts;
| ^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue rust-lang#130364 <rust-lang#130364> for more information
= help: add `#![feature(box_vec_non_null)]` to the crate attributes to enable
= note: this compiler was built on 2026-01-15; consider upgrading it if it is out of date
error[E0658]: use of unstable library feature `const_heap`
--> src/main.rs:3:5
|
3 | Vec::<()>::const_make_global;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue rust-lang#79597 <rust-lang#79597> for more information
= help: add `#![feature(const_heap)]` to the crate attributes to enable
= note: this compiler was built on 2026-01-15; consider upgrading it if it is out of date
```
Most of the remaining reasons after this are something similar to "this is an implementation detail for XYZ" or "this is not public". If this PR is approved, I'll look into those next.
The PR also removes the `fd_read` feature gate. It only consists of one attribute applied to an implementation inside a module that is already private and unstable and should not be needed.
thread, grid, and block dim/idx can only return non-negative values
When `[u8]::is_ascii()` is compiled with `-C target-cpu=native` on AVX-512 CPUs, LLVM generates inefficient code. Because `is_ascii` is marked `#[inline]`, it gets inlined and recompiled with the user's target settings. The previous implementation used a counting loop that LLVM auto-vectorizes to `pmovmskb` on SSE2, but with AVX-512 enabled, LLVM uses k-registers and extracts bits individually with ~31 `kshiftrd` instructions. This fix replaces the counting loop with explicit SSE2 intrinsics (`_mm_loadu_si128`, `_mm_or_si128`, `_mm_movemask_epi8`) for x86_64. `_mm_movemask_epi8` compiles to `pmovmskb`, forcing efficient codegen regardless of CPU features. Benchmark results on AMD Ryzen 5 7500F (Zen 4 with AVX-512): - Default build: ~73 GB/s → ~74 GB/s (no regression) - With -C target-cpu=native: ~3 GB/s → ~67 GB/s (22x improvement) The loongarch64 implementation retains the original counting loop since it doesn't have this issue. Regression from: rust-lang#130733
remove `impl Neg` on s390x/powerpc vector types
…i-obk Add `const Default` impls for `HashSet` and `HashMap` with custom `Hasher` Follow up to rust-lang#134628. Tracking issue rust-lang#143894. r? @fmease cc @fee1-dead @oli-obk This doesn't allow for `const H: HashSet<()> = Default::default();`, but would allow for it to work with a custom hasher, which would enable the `Fx*` family to work.
…ottmcm Stabilize `alloc_layout_extra` Tracking issue: rust-lang#55724 FCP completed in rust-lang#55724 (comment) Closes rust-lang#55724 ---- As per rust-lang#55724 (comment), - `repeat_packed` and `extend_packed` are unchanged - `repeat` now excludes trailing padding on the last element from the total array size - `dangling` renamed to `dangling_ptr` - `padding_needed_for` not stabilized, changed to accept `Alignment` instead of `usize` and moved to the `ptr_aligment_type` feature flag (tracking issue: rust-lang#102070)
…-Simulacrum time: Add saturating arithmetic for `SystemTime` This commit implements the following methods: * `SystemTime::saturating_add` * `SystemTime::saturating_sub` * `SystemTime::saturating_duration_since` The implementation of these methods is rather trivial, as the main logic lies behind the constants `SystemTime::MIN` and `SystemTime::MAX`. See also: * Accepted ACP: rust-lang/libs-team#718 * Tracking Issue: rust-lang#151199
Change field `bit_width: usize` to `bits: u32` in type info Follow-up rust-lang#151123 (comment). Quotes: @Skgland: > > I'm not sure whether we should use `usize` or `u64` here to represent the bit width. > > My expectation would be `u32` matching the associated `{u,i}N::BITS`[^1][^2][^3] constant that already exists on the integer types. > > [^1]: https://doc.rust-lang.org/std/primitive.i8.html#associatedconstant.BITS > [^2]: https://doc.rust-lang.org/std/primitive.i128.html#associatedconstant.BITS > [^3]: https://doc.rust-lang.org/std/primitive.usize.html#associatedconstant.BITS @SpriteOvO: > I found some [previous discussions](rust-lang#76492 (comment)) regarding the type of `::BITS` constant. And during the stabilization of `::BITS`, the choice of `u32` affected some ecosystem crates (rust-lang#81654), but soon after, these crates all accepted the `u32` type. > > So I think it makes sense to keep the type consistent with `::BITS` here. Then I'd also like to change the name from `bit_width` to `bits`, also for consistency. r? @oli-obk
Include a link to `count_ones` in the docs for `uN::count_zeros` [docs only] I did not update `iN` because `count_zeros` is reasonable for *negative* numbers. Rendered: <img width="1188" height="524" alt="image" src="https://github.com/user-attachments/assets/80ebf53c-3cde-4230-b436-d2148b07d4c8" /> <img width="1186" height="517" alt="image" src="https://github.com/user-attachments/assets/544d2ff4-ee35-44f7-8d50-65fc5f0ff3c9" />
This commit removes a repetitive match statement in favor of Option::map for Option::cloned.
fix: thread creation failed on the wasm32-wasip1-threads target. wasm32-wasip1-threads target cannot create thread since nightly-2026-01-16. This commit (c1bcae0) broken it. It in rust-lang#151016 This pull-request fix that issue.
For inputs smaller than 32 bytes, use usize-at-a-time processing instead of calling the SSE2 function. This avoids function call overhead from #[target_feature(enable = "sse2")] which prevents inlining. Also moves CHUNK_SIZE to module level so it can be shared between is_ascii and is_ascii_sse2.
std: implement `sleep_until` on Apple platforms On Apple platforms, `nanosleep` is internally [implemented](https://github.com/apple-oss-distributions/Libc/blob/55b54c0a0c37b3b24393b42b90a4c561d6c606b1/gen/nanosleep.c#L281) using `mach_wait_until`, a function that waits until a deadline specified in terms of `mach_absolute_time`. Since `mach_wait_until` is [public](https://github.com/apple-oss-distributions/xnu/blob/f6217f891ac0bb64f3d375211650a4c1ff8ca1ea/osfmk/mach/mach_time.h#L50-L51)[^1], we can use it to implement `sleep_until` by converting `Instant`s (which are measured against `CLOCK_UPTIME_RAW`, which is equivalent to `mach_absolute_time`) into `mach_absolute_time` values. Related tracking issue: rust-lang#113752 [^1]: It's badly documented, but it's defined in the same header as `mach_absolute_time`, which `std` used to use for `Instant` before rust-lang#116238.
Support pointers in type reflection Tracking issue: rust-lang#146922 This PR adds support for inspecting pointers `*const T` and `*mut T` through type reflection. It does so by adding the new `Pointer` struct + variant: ```rust pub struct Pointer { /// The type of the value being pointed to. pub ty: TypeId, /// Whether this pointer is mutable or not. pub mutable: bool, } ``` This can be gathered using `Type::of`, for example: ```rust match const { Type::of::<*const u8>() }.kind { TypeKind::Pointer(pointer) => { assert_eq!(pointer.ty, TypeId::of::<u8>()); assert!(!pointer.mutable); } _ => unreachable!(), } ```
…=Amanieu compiler: upgrade to hashbrown 0.16.1 See also rust-lang#135634, rust-lang#149159, and rust-lang/hashbrown#662. This includes an in-tree upgrade of `indexmap` as well, which uses the new `HashTable` buckets API internally, hopefully impacting performance for the better. And finally, we can remove `#[rustc_unsafe_specialization_marker]` on `Copy`! cc @joboet r? @Amanieu
Mark the neon intrinsics as inline(always).
Rollup of 11 pull requests Successful merges: - rust-lang#151378 (Codegen tests for Arm Cortex-R82) - rust-lang#151936 (Move the `fingerprint_style` special case into `DepKindVTable` creation) - rust-lang#152018 (Move bigint helper tracking issues) - rust-lang#151958 (Add codegen test for SLP vectorization) - rust-lang#151974 (Update documentation for `Result::ok()`) - rust-lang#151975 (Work around rustfmt giving up on a large expression) - rust-lang#151990 (Fix missing unused_variables lint when using a match guard) - rust-lang#151995 (stabilize ptr_as_ref_unchecked) - rust-lang#151999 (attribute parsing: pass recovery mode to Parser.) - rust-lang#152009 (Port rustc_preserve_ub_checks to attr parser) - rust-lang#152022 (rustc-dev-guide subtree update) Failed merges: - rust-lang#151968 (Remove `HasDepContext` by merging it into `QueryContext`)
fN::BITS constants for feature float_bits_const Also enables the feature for compiler_builtins as otherwise this causes a warning and conflicts with the Float extension trait. --- Implementation for rust-lang#151073 Feature flag: `#![feature(float_bits_const)]` Note that this is likely to conflict with some extension traits, as it has with compiler builtins. However, assuming correct values for the constants, they are either `u32`, the same type, which should not cause a problem (as shown by enabling the feature for compiler_builtins), or a different type (e.g. `usize`), which should cause a compiler error. Either way this should never change behaviour unless the extension trait implemented an incorrect value. Also note that it doesn't seem to be possible to put multiple unstable attributes on an item, so `f128::BITS` and `f16::BITS` are gated behind the feature flags for those primitives, rather than `#![feature(float_bits_const)]`
…-Simulacrum disable socket tests in Miri rust-lang#150428 added some tests that do not work in Miri since we do not support sockets. r? @Mark-Simulacrum
…follow-on-windows, r=ChrisDenton Fix set_times_nofollow for directory on windows Fix issue from: rust-lang#147455 (comment) old code `opts.write(true)` on Windows requests `GENERIC_WRITE` access, replace with `opts.access_mode(c::FILE_WRITE_ATTRIBUTES)` to get minimal permission. r? @joshtriplett
![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.
The conflict resolution in the previous commit left core uncompilable; notably, a single unresolved import cascaded into thousands of misleading 'multiple applicable items in scope' (E0034) and 'duplicate diagnostic item' errors, obscuring the few real problems: * intrinsics/mod.rs kept both sides' va_list imports; upstream removed VaListImpl in favor of VaList (rust-lang#141980), so drop the stale import. * Upstream turned Alignment from a tuple struct into a struct with a named field _inner_repr_trick, breaking our type invariant and the kani::Arbitrary impl, both of which referenced field 0. * Upstream changed Layout::padding_needed_for to take Alignment instead of usize and renamed Layout::dangling to Layout::dangling_ptr; adjust our ensures clauses and harnesses accordingly. With these changes both a plain 'cargo check -p core' and the cfg(kani) build via 'kani list' complete without errors, unblocking the Kani List, Kani Metrics, Kani Autoharness Analyzer, goto-transcoder and partition CI jobs that all failed with the same compilation errors. Co-authored-by: Kiro <kiro-agent@users.noreply.github.com>
Upstream changed Alignment::as_usize to be implemented in terms of as_nonzero (to let MIR optimizations fold the pair away). Our postcondition on as_nonzero references self.as_usize(), which now makes the contract instrumentation mutually recursive: checking as_nonzero's contract evaluates as_usize, whose body calls the instrumented as_nonzero again. Under Kani this manifested as unbounded recursion unwinding (tens of thousands of iterations) until CBMC ran out of memory, failing e.g. the alloc::layout harnesses. Reference the underlying field directly in the postcondition instead, mirroring what the type invariant already does. Verified locally with the pinned Kani commit: check_dangling, check_padding_needed_for and check_pad_to_align all pass. Co-authored-by: Kiro <kiro-agent@users.noreply.github.com>
Two harness failures surfaced in CI once compilation was fixed: * alloc::layout::verify::check_repeat: rust-lang#148769 changed Layout::repeat to not include padding after the trailing element, so on success the resulting size is (n - 1) * stride + self.size() rather than n * stride. Our postcondition size >= stride is thus violated for n == 1 whenever self needs padding (e.g. size 6, align 4: size 6 < stride 8). Update the exact (non-kani) postconditions to the new semantics and weaken the Kani-checkable variant to n <= 1 || size >= stride. * num::verify::checked_f128_to_int_unchecked_i128: Kani's f128 -> i128 lower bound in float_to_int_in_range is unsound (-2^128 instead of -(2^127 + 2^15)), so the contract instrumentation admits values that truncate below i128::MIN; the CBMC 6.10 upgrade in the new Kani pin exposed this (previously such conversions happened to saturate the same way as the 'as' oracle). Reported as model-checking/kani#4662, fix proposed in model-checking/kani#4663. Until that fix is in the pinned Kani version, hand-write this harness with an explicit sound input range. Verified locally with the pinned Kani commit: both harnesses pass, and 'cargo check -p core' stays clean. Co-authored-by: Kiro <kiro-agent@users.noreply.github.com>
The previously pinned Flux (27e3ef52b522) is built for
nightly-2025-11-25 and cannot process this branch's library sources
("cannot find a built-in macro with name 'eii'"), failing the
check-flux-on-core CI job.
Flux upstream has not yet merged a toolchain upgrade past
nightly-2025-11-25 into main, but its toolchain-upgrade branch (open
PR flux-rs/flux#1345) contains the required rustc API adaptations.
Pin 67d714e90ce7 ("Fix rustc API change for queries module in
nightly-2026-02-05"), the commit on that branch whose pinned
toolchain exactly matches this repository's nightly-2026-02-05. The
branch's later commits (nightly-2026-02-09) do not build with their
own toolchain pin (missing the fallback_fluent_bundle adaptation,
flux-rs/flux#1507).
The liquid-fixpoint pin stays at nightly-01-14-2026, which is still
the newest pinned release.
One Flux regression surfaced by the new version: the value refinement
is no longer propagated through the From<u8> for usize impl, so the
HEX_DIGITS array accesses in AsciiChar's Debug impl (a use of
usize::from on values provably < 16) could not be proven in bounds
anymore. Work around this by using 'as usize' casts, which Flux still
reasons about precisely; semantics are unchanged (u8 -> usize is
lossless).
Verified locally: 'cargo flux -p core' passes with the new pin (232
functions checked, 0 errors), and 'cargo check -p core' stays clean.
Co-authored-by: Kiro <kiro-agent@users.noreply.github.com>
The previous commit blamed Flux for no longer propagating value
refinements through the From<u8> for usize impl. That diagnosis was
wrong: upstream rewrote the impl_from! macro in convert/num.rs, and
the merge dropped our
#[cfg_attr(flux, flux::spec(fn(small: $Small) -> $Large[cast(small)]))]
annotation from it, so plain Flux (old or new) has no exact spec for
the widening integer conversions. Restore the annotation on the new
macro and revert the ascii_char.rs workaround, which is no longer
needed.
Verified locally with Flux 67d714e90ce7: 'cargo flux -p core' passes
on the unmodified AsciiChar code (232 functions checked, 0 errors),
and 'cargo check -p core' stays clean.
Co-authored-by: Kiro <kiro-agent@users.noreply.github.com>
|
Looks like kiro-agent found an old stale commit for flux. I created #614 targeting this branch to update to the latest version |
Member
@nilehmann In fact intentionally so, though that could still be wrong (but CI is passing): note that we are only upgrading to nightly-2026-02-05 here, not yet to the much newer version that #614 would support. Would picking up your newer version still be safe? That would obviously be great for it would spare us further git archeology. |
|
#614 targets |
Both ubuntu-latest 'Verify std library (partition 1)' jobs died with 'The runner has received a shutdown signal' while verifying the ffi::c_str harnesses; the macos jobs passed. run-kani.sh passes -j (one thread per core) to kani, so the 4-core/16 GB ubuntu runners verify four harnesses concurrently. With the new Kani/CBMC pin the c_str harnesses have grown memory-hungry - measured individually with CI-equivalent flags (--no-assert-contracts, --object-bits 12): check_from_bytes_with_nul 9.6 GB check_to_str 5.4 GB check_as_ptr 3.1 GB check_bytes 3.1 GB check_count_bytes 1.7 GB Four such harnesses in flight exceed 16 GB, OOM-killing the runner. Introduce KANI_JOBS to let CI cap the number of parallel harnesses and set it to 2 for the ubuntu partition jobs. The heaviest known cluster (the four c_str harnesses above) then peaks at ~13.4 GB of concurrent solver memory (measured by sampling the process tree), which fits the runner with headroom to spare. macos jobs keep the full -j behavior. Co-authored-by: Kiro <kiro-agent@users.noreply.github.com>
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.
The 'Verify std library using autoharness (macos-latest)' jobs fail in their manual-harness phase: ffi::c_str::verify::check_from_bytes_with_nul exceeds the 10-minute --harness-timeout on the 7 GB macos-latest runners. The root cause is a large memory-usage increase in CBMC 6.10 (pinned by the current Kani version): measured locally with CI-equivalent flags, the harness needs 9.6 GB with CBMC 6.10 versus 5.1 GB with CBMC 6.7.1, so the macos runners swap until the timeout expires. The ubuntu autoharness jobs (16 GB) and the partition jobs (no harness timeout) still passed. Alternative SAT solvers don't help: the blowup is in CBMC itself (kissat drops memory to 1.7 GB but runs for over 40 minutes; cadical matches the default's 9.6 GB). Reduce the harness bound from MAX_SIZE 16 (unwind 17) to 8 (unwind 9), which brings it down to 2.6 GB and ~1.5 minutes locally, comfortably within the macos runner budget even with three harnesses verified in parallel. Co-authored-by: Kiro <kiro-agent@users.noreply.github.com>
tautschnig
approved these changes
Jul 21, 2026
|
@btj can you take a look at the VeriFast failures? |
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-11-25 (rust-lang/rust@c871d09) to 2026-02-05 (rust-lang/rust@db3e99b) (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: 7206615