Repository navigation
Merge subtree update for toolchain nightly-2026-10-11 - #727
Open
github-actions[bot] wants to merge 10000 commits into
Open
github-actions[bot] wants to merge 10000 commits into
github-actions[bot] wants to merge 10000 commits into
Conversation
alloc: stabilise `Allocator` # Allocator stabilisation report Reference PR: - rust-lang/reference#2364 This is the stabilisation report for a subset of the feature `allocator_api`, with tracking issue [rust-lang#32838](rust-lang#32838) under the purview of wg-allocators, initially proposeed by [RFC rust-lang#1398](https://rust-lang.github.io/rfcs/1398-kinds-of-allocators.html). The remainder of the feature will be renamed to `allocator_ext`. This was a collaborative effort of t-libs, wg-allocators, members of t-types, t-lang, and t-opsem, alongside interested parties in the ecosystem and contributors to the initial attempt at stabilisation on GitHub. See also the new [wg-allocators roadmap](rust-lang/wg-allocators#150) on the matter. ## Summary The following is a proposal following several conversations, [in-person](rust-lang/all-hands-2026#48) and [online](https://rust-lang.zulipchat.com/#narrow/channel/197181-t-libs.2Fwg-allocators), with libs team members and interested ecosystem participants and represents an attempt at stabilising an MVP for the `Allocator` trait and its implementation safety requirements, alongside minimal functionality to make its use possible in the standard library. While an effort was made to align with the stated positions of the team, the opinions and rationale stated are **the author's own**, and should **not** be seen as representative of the libs(-api) team as a whole except insofar as individual members therein choose to endorse the contents of report. Any mention of "we", "us", etc. should be understood to refer to the author alongside those who have explicitly expressed agreement. ## API & considerations The stabilised API surface consists of: ```rust unsafe trait Allocator { // Required methods fn allocate(&self, layout: Layout) -> Result<NonNull<[u8]>, AllocError>; unsafe fn deallocate(&self, ptr: NonNull<u8>, layout: Layout); // Provided methods fn allocate_zeroed( &self, layout: Layout, ) -> Result<NonNull<[u8]>, AllocError> { ... } unsafe fn grow( &self, ptr: NonNull<u8>, old_layout: Layout, new_layout: Layout, ) -> Result<NonNull<[u8]>, AllocError> { ... } unsafe fn grow_zeroed( &self, ptr: NonNull<u8>, old_layout: Layout, new_layout: Layout, ) -> Result<NonNull<[u8]>, AllocError> { ... } unsafe fn shrink( &self, ptr: NonNull<u8>, old_layout: Layout, new_layout: Layout, ) -> Result<NonNull<[u8]>, AllocError> { ... } } // N.B.: This particular point is lang-relevant since `Box` // would be stabilised without being fundamental over `A`. struct Box<T, #[stable(...)] A: Allocator>(...) impl<T, A: Allocator> Box<T, A> { fn new_in(x: T, alloc: A) -> Box<T, A>; } impl<T: ?Sized, A: Allocator> Box<T, A> { unsafe fn from_raw_in(raw: *mut T, alloc: A) -> Self; unsafe fn from_non_null_in(raw: NonNull<T>, alloc: A) -> Self; fn into_raw_with_allocator(b: Self) -> (*mut T, A); fn into_non_null_with_allocator(b: Self) -> (NonNull<T>, A); fn allocator(b: &Self) -> &A; } struct Vec<T, #[stable(...)] A: Allocator> { ... } impl<T, A: Allocator> Vec<T, A> { fn new_in(alloc: A) -> Vec<T, A>; fn with_capacity_in(capacity: usize, alloc: A) -> Self; unsafe fn from_raw_parts_in( ptr: *mut T, length: usize, capacity: usize, alloc: A, ) -> Self; unsafe fn from_parts_in( ptr: NonNull<T>, length: usize, capacity: usize, alloc: A, ) -> Self; fn into_raw_parts_with_allocator(self) -> (*mut T, usize, usize, A); fn into_parts_with_allocator(self) -> (NonNull<T>, usize, usize, A); fn allocator(&self) -> &A; } struct Global; // implementor of Allocator struct System; // implementor of Allocator unsafe impl<A: Allocator + ?Sized> Allocator for &A { ... } unsafe impl<A: Allocator + ?Sized> Allocator for &mut A { ... } unsafe impl<A: Allocator + ?Sized> Allocator for Box<A, _> { ... } unsafe impl<A: Allocator + ?Sized> Allocator for Rc<A, _> { ... } unsafe impl<A: Allocator + ?Sized> Allocator for Arc<A, _> { ... } ``` The `by_ref` method on `Allocator` was removed, as it was only a postfix syntax convenience (equivalent to writing `(&alloc)`). The safety requirements on implementors of `Allocator` were tightened to the most restrictive sound form we expect to possibly want, in order to enable us to iterate on the design in the future and relax these bounds if it is deemed possible. Notable changes from the form assumed before the stabilisation effort started: - the implicit requirement that the standard library's `Clone for Arc<T, A>` implementation relied on but was improperly documented, for implementors not to invalidate allocated memory on drop or mutable access was made explicit; - implementors are now required not unwind from any of the methods on the trait or from drop; - the safety invariants implementors of `Allocator + Clone` must uphold were moved to their own unstable marker subtrait as the requirement was deemed unjustifiable. Additionally, [it was decided](rust-lang#156906) that `Allocator` will be `dyn`-compatible, as the resulting constraints on the design were deemed acceptable given the significant increased flexibility for users. ## Soundness developments The process of attempting stabilisation resulted in several soundness issues arising, especially with regard to the interaction between custom allocators and `Box`es. Thus, some points had to be adjusted: - there existed a requirement for trait implementors to obey certain semantics if an implementor of `Allocator` is also `Clone`, which constituted possible UB if broken. These have been dropped, as unsafe implementors [cannot guard against possible unsoundness](rust-lang#156920) from incorrect implementations in downstream safe code, but the equivalent functionality may be added backwards-compatibly with an unsafe marker trait or language mechanism; - `Box::into_pin` will not yet be possible with custom allocators. This is because of a [soundness bug](rust-lang#157089) relating to an interaction between the possibility of manually implementing `Clone for Box<T, A>` and `Box` being covariant over `A`, allowing for a pinned box to be cloned with a non-`'static` allocator from one with a correct `'static` allocator subtyped to a non-static one. Making `Box` invariant over the allocator was considered, but was deemed far too limiting and would technically be a [breaking change](rust-lang#153607) to reverse later. Thus, for now, an unstable and unsafe marker trait `StaticAllocator` will be introduced to mark an allocator as guaranteeing that its allocations live for `'static` (i.e. will never be lost unless explicitly de/reallocated). This will be implemented for the `Global` and `System` allocators; - due to `Pin`'s preexisting implementation of a safe `Pin::new` for any pointer type where `<Ptr as Deref>::Target: Unpin`, it *will* be stably possible to call `Pin::new()` on a box with a custom allocator as changing this would require significant special-casing in trait resolution. Experiments in this direction surfaced a [soundness bug](rust-lang#159445 (comment)), addressed by tightening the requirements of `impl PinSafePointer for Box` to necessitate a pin-safe `StaticAllocator`; - further discussion revealed that these same semantics are necessary for integrating custom allocators into LLVM's proposed semantics for allocator intrinsics, as below; - a preexisting hack whereby `Box` had `noalias` semantics for its pointer if and only if the allocator is `Global` - alongside a similar hack to make ["unleaking"](https://doc.rust-lang.org/std/boxed/struct.Box.html#method.leak) work - is to be moved to an unstable wrapper type `NativeAllocator<A: StaticAllocator>`, which enables us to make use of LLVM's new [allocator intrinsics](https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/Enabling.20compiler.20magic.20on.20custom.20allocators). `Global` would then be equivalent to `NativeAllocator<A>` with the concrete allocator substituted in. Per a conversation with members of opsem, this appeared to be a reasonable way forward; - unwinding out of many allocation-related methods was found to be a pervasive source of unsoundness. Thus, language on allocator cloning and allocation methods was expanded so as to ensure unwinds never come out of methods on an `Allocator`, clones, or drops. ## Backwards-compatible changes Several designs were considered to extend or modify the trait's semantics. We have opted to defer full consideration of many of these for later, as we have determined they can be added backwards-compatibly to the existing API. A list of these is present below, alongside rationale for their postponement. ### `Store` API This is an alternative, more complex proposal for custom allocators (see the [draft RFC](rust-lang/rfcs#3446)). Per a conversation in-person with one of the authors of the `Store` proposal, we have established that it could be added backwards-compatibly (in `Store` terminology, the stabilised `Allocator` trait is effectively a storage with pointer handles). The details were thus deferred for potential post-stabilisation changes. ### Split `Deallocator` trait [Supertrait item shadowing](rust-lang#89151) alongside a blanket `impl<A: Allocator + ?Sized> Deallocator for A` will allow us to add a `Deallocator` supertrait backwards-compatibly, and to relax the requirements for collection types to insted hold a `Deallocator`. Conversations with those involved in the above issue suggest it is likely for a PR implementing this to be merged in the near future. ### `fn reallocate()` The current design uses dedicated `grow`, `grow_zeroed`, and `shrink` methods instead of a way to reallocate between arbitrary sizes. However, such a function could be added with a defaulted body in the future, forwarding to the extant `grow`/`shrink` implementations. ### Conditional reentrancy in `std` Not all allocators will be [reentrant in `std`](rust-lang/libs-team#743), and thus the standard library may want to be able to conditionally call the global allocator in areas it has otherwise promised not to. Thus, the proposed unstable `GlobalAllocator: Allocator` marker trait could be extended with a defaulted associated constant `REENTRANT_IN_STD: bool = true` wherein implementors could promise that a certain allocator never calls *any* part of `std`. ## Possible but less clean additions Several options appeared to signal compelling usecases, but were sufficiently niche that we did not consider them to be blocking for an MVP stabilisation so long as it was realistically possible to express their semantics. ### Associated constants Several usecases would be facilitated by having certain associated items on the `Allocator` trait; notably, `const MIN_ALIGN: usize` for the minimum alignment an allocator is always guaranteed to return. Adding the semantics of these backwards-compatibly would rely on maybe trait bounds being stabilised, which per conversations with the lang & types teams we believe is feasible in the near future. Alternatively, much of the same functionality could be added with defaulted `const` methods, which are also on the stabilisation path. ### `grow_in_place()` There is currently no obvious way to signal through the API whether a move of the data is acceptable when reallocating memory. Though messy, a way to express these semantics with the current design does exist, even if non-obvious: ```rust struct A; // `grow`/`grow_zeroed` have non-in-place semantics unsafe impl Allocator for A { /* ... */ } struct B(A); // in-place-grow semantics unsafe impl Allocator for B { /* ... */ } impl A { fn as_pinning(self) -> B { B(self) } } impl B { fn as_nonpinning(self) -> A { self.0 } } ``` We have decided that this is acceptable, given that it is "only" a point of design and not underlying functionality. A cleaner way to signal such semantics would be of interest for future extensions to the trait. Notably, in-place growing and/or shrinking without invalidating preexisting pointers (i.e. actually changing the size of the allocation in the abstract machine) needs proper support from LLVM which may not happen in the near future. ### Allocation flags A similar transmute-based mechanism as for the above can be used to reference a local inside of the allocator, though this could be UB-prone. Alternatively, and much more nicely, argument splatting could allow us to backwards-compatibly extend the trait (assuming implementors as well as callers may ignore optional fields). However, this would depend on the details of such a proposal. The main stakeholder who approached us with concerns on this topic - Rust for Linux - signalled willingness to maintain a downstream extension trait for such functionality for the time being. ## Rejected alternative proposals The following changes were explicitly not made to the API pre-stabilisation, despite it being unlikely that their semantics could be nicely expressed in the (near) future. In all cases, notable arguments existed to make the requested change, but we decided they were not sufficiently compelling. Should a way to express these semantics emerge in the future backwards-compatibly, we would be open to re-reviewing them. ### `NonZeroLayout` arguments An idea had been proposed to change the signature of the allocating/freeing methods to take a `Layout` that is guaranteed to have a nonzero size. We determined that API cleanliness and potential simplification of library code (once `const Trait`s are stable, collection types could drop special-case logic when using a `const Allocator` at zero capacity) outweigh the arguments for not allowing zero-sized allocations. As we see it, in the cases where it would genuinely be problematic, this will only move the branch on zero-sized allocation to the other side of the call. At worst, it would put marginally more pressure on a branch predictor. Though the possibility of zero-size allocations being probematic is often mentioned, we have not seen sufficiently convincing concrete cases where this is the case. One pointed-to example was that of highly performance-sensitive allocators (e.g. bump allocators); however, it appears most of these cases can trivially support zero-size allocations (e.g. bumping by zero). Consequently, we have decided to keep the nicer logic for downstream users of the trait. An argument had also been made around `jemalloc` being unable to correctly handle zero-sized allocations, but this appears to only apply to internal APIs. A similar idea wherein `allocate` was an unsafe method and support for zero-sized allocations was implementation-defined was rejected on similar usability grounds. Several members of the libs team expressed their opinion that the design of `GlobalAlloc` (featuring a similar unsafe allocating method wherein the caller must guarantee the size is nonzero) was not desirable in hindsight. ### `NonNull<u8>` return type Lacking a better way to signal returned vs. requested capacity, and not wishing to duplicate all of the allocating methods, we have decided that we would prefer to keep the wide-pointer return value and potentially use that logic to determine capacity in returned allocations. This will never be an issue with regard to performance, as no architecture allocates expects fewer than two registers to be clobbered by a function call, and so there is no cost to returning the wide pointer. Some callers will elect to ignore extra capacity; similarly, some implementors will elect not to offer it. The language around implementation safety ensures that these cases are supported, and recommends that implementors not signal extra capacity if it would be expensive to do so. That is to say, both the caller and implementor must cooperate for the excess to be meaningfully usable; otherwise there is no performance impact in a correct implementation. ### Associated types Having an associated type, especially for the returned error on allocation failure, had been mentioned as a possible addition; however, doing so would add significant complexity to the trait while also making `dyn`-compatibility impossible. Few concrete usecases came up where the allocator itself has meaningful error information that would be actionable to callers, and therefore it was elected to keep the current ZST `AllocError`. ## Future work A large part of the standard library will need review as we determine what the correct way is for various collection and pointer types to work with custom allocators. Notably, there are multiple outstanding proposals for integrating fallible allocation APIs into the standard library, and a stable mechanism needs to be decided on for exposing the `Allocator` + `Clone` interaction. ## Outlined potential extensions The following is a possible future outline of what the `Allocator` trait and related might look like under this proposal, assuming both of supertrait item shadowing and defaulted associated items being added: ```rust unsafe trait Allocator: Deallocator { fn allocate( &self, layout: Layout, ) -> Result<NonNull<[u8]>, AllocError>; unsafe fn deallocate( &self, ptr: NonNull<u8>, layout: Layout, ); // Provided methods unsafe fn reallocate( &self, ptr: NonNull<u8>, old_layout: Layout, new_layout: Layout, ) -> Result<NonNull<[u8]>, AllocError> { ... } /// Minimum alignment that will always be returned, regardless /// of what alignment is requested. const fn min_align(&self) -> usize { 1 } } unsafe trait Deallocator { unsafe fn deallocate(&self, ptr: NonNull<u8>, layout: Layout); } // Enabled by supertrait item shadowing. impl<A: Allocator> Deallocator for A { unsafe fn deallocate(&self, ptr: NonNull<u8>, layout: Layout) { <Self as Allocator>::deallocate(self, ptr, layout) } } /// The allocator is suitable for use as the global allocator. /// /// # Safety /// /// `reentrant_in_std` must never be `false` incorrectly, and /// if `true`, the allocator may only use those parts of `std` /// which explicitly allow themselves to be called from the global /// allocator (such as thread-locals). unsafe trait GlobalAllocator: Allocator + Sync + 'static { const REENTRANT_IN_STD: bool; } /// `Clone` will create an equivalent (de)allocator (i.e. both /// can deallocate the same memory), and `Copy` either is /// the same as clone (i.e. `Clone` is a memcpy) or impossible /// to implement. unsafe trait AllocatorClone: Deallocator + Clone {} /// Polls allocator equivalence. unsafe trait AllocatorEq<Other: AllocatorEq = Self>: Deallocator { /// If `other` can free something, so can `self`. /// Implementors must never incorrectly return `true`, /// and equality must be transitive and reflexive. fn is_equivalent(&self, other: &Other) -> bool; } /// The allocator in question will not break `Pin` guarantees /// even if subtyped with a shorter lifetime; that is, memory /// is never deallocated except via an explicit call to `deallocate` /// (and not via dropping the allocator, etc.). unsafe trait StaticAllocator: Allocator {} impl<T, A, D> Box<T, D> where A: Allocator + AllocatorEq<D>, D: AllocatorEq<A>, { // bikeshed better names fn new_in_with(x: T, alloc: A, dealloc: D) -> Self { if dealloc.is_equivalent(&alloc) { unsafe { Box::new_in_with_unchecked(...) } } } fn with_dealloc(boxed: Box<T, A>, dealloc: D) -> Self { ... } } impl<T, A: StaticAllocator> Box<T, A> { fn into_pin(boxed: Box<T, A>) -> Pin<Box<T, A>> { ... } } /// Calls to this allocator are not considered part of program /// behaviour, and thus may be elided or created by the optimiser. /// Additionally, such an allocator will never return an excess /// and makes no promises about alignment beyond what is requested. #[lang = "native_allocator"] struct NativeAllocator<A: StaticAllocator>(A); impl<A: StaticAllocator> Allocator for NativeAllocator<A> { ... } impl<A: StaticAllocator> StaticAllocator for NativeAllocator<A> {} ``` cc @rust-lang/libs @rust-lang/libs-api @rust-lang/opsem r? libs
…ked, r=LawnGnome implement (OnceLock,LazyLock)::(get_unchecked,get_unchecked_mut) Tracking issue: rust-lang#162716 Based on the original work of @HomelikeBrick42 from rust-lang#138914.
…cs, r=nia-e Make it clear what the alignment needs to be for `deallocate` As noticed on [zulip](https://rust-lang.zulipchat.com/#narrow/channel/197181-t-libs.2Fwg-allocators/topic/Question.3A.20layout.20alignment.20for.20Allocator.3A.3Adeallocate.28.29/with/626111397), this is insufficiently precise r? clarfonthey
Co-authored-by: Boxy <rust@boxyuwu.dev>
…Titor std: Update `wasip3` crate dependency Keeping it up-to-date and resolving minor issues with it.
rename direct_const_arg! to gca! Also re-export it from `std`, and make most tests `use std::gca;` rather than writing out `core::` every time the macro is called. Part of the design rework discussed in Zulip [#project-const-generics > talkies at last @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/260443-project-const-generics/topic/talkies.20at.20last/near/620368825) r? @BoxyUwU
Fix Typo in `std::sys::process::unix::unsupported::wait_status` Docs Noticed while collecting data on conditional compilation for potential aliasing (see [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Using.20.60build.2Ers.60.20for.20cfg.20aliases.20in.20.60std.60/with/625458363) for details) that this attribute was missing its closing brace. Extremely trivial, might as well fix it!
…bit, r=tgross35 Fix flt2dec build on 16-bit targets Closes rust-lang#163158. Fixes build breakage rust-lang#162879 on the two 16-bit targets, `avr-none` and `msp430-none-elf`, by including `target_pointer_width = "16"` in all the cfg attributes for the u32 implementations for bignum and flt2dec.
…t-tests improve simd bitshift tests
Pull from rust-lang/rust
FreeBSD 13.1 had introduced a sched cpu affinity compatibility layer with Linux. 13.0 and even 13.1 being EOL, we can simplify here.
This reverts commit 95d43bf. Now that closures have field retagging again, we need this MaybeDangling again.
…r, r=Darksonn Add `inline` attribute to `NonZero::from_str` `<integer>::from_str`, `T::from_str_radix`, `T::from_ascii_bytes`, and `T::from_ascii_bytes_radix` has the `inline` attribute, buy `NonZero::from_str` does not.
…nthey std::thread::available_parallelism merging linux/android/freebsd version FreeBSD 13.1 had introduced a sched cpu affinity compatibility layer with Linux. 13.0 and even 13.1 being EOL, we can simplify here.
Adjust implementation to reduce MIR generated.
…thlin give noalias back to refs in closures Reverts parts of rust-lang#160745 to fix rust-lang#163220. Needs team approval; FCP is happening in rust-lang#163220.
…r, r=scottmcm
Refactor `core::cmp::{smallest, largest}` & add `mir-opt` test
Tracking Issue: rust-lang#160728
# Description
Based on [this](rust-lang#160687 (comment)) feedback from the initial implementation, I've added a `mir-opt` test to highlight the amount of MIR added by using a variadic `min` implementation. ~~To my knowledge, there isn't a way to actually test the MIR generated by the actual implementation in `core`, so I've replicated a smaller representative sample in a test instead. Please see [GodBolt](https://godbolt.org/z/1qGzboeo3) for a more detailed comparison between the (unoptimised) MIR for the current and splatted versions of `min` (`max` omitted since it's identical).~~
~~In short, the splat version does produce more MIR, especially for the additional trait implementations for larger tuple sizes. However, the added MIR almost exclusively comes from the indirection of calling a method on a trait, and not specifically the `#[rustc_splat]` variadic implementation. Because of this, it may be worth considering a MIR pass which could inline this kind of static dispatch.~~
Moving to a pre-codegen test with some MIR optimisation has narrowed the gap between `smallest` and `min` to basically nothing (an extra scope from the looks of it). I'm guessing the chained `a.min(b).min(c).min(d)` style (with a lack of explicit temporaries) is something MIR is able to readily optimise!
From experimenting with this test, I also found a simpler way to implement `smaller` and `larger`. The most notable difference is instead of passing all arguments through the splat, I've pulled out the first argument so they aren't de/tupled. It improves codegen slightly, but more importantly simplifies the macro implementation.
---
## Notes
- No AI tooling of any kind was used during the creation of this PR.
…richton Mark `std::os::wasip2` with correct doc-cfgs, mark as unstable r? @alexcrichton So, initially went through a bit thinking this was secretly stable since Rust 1.78.0 but it turns out that rustdoc was just not displaying this correctly, as it wasn't set up like the other modules. Even though this can't actually be accessed without the `wasip2` feature (I think), I decided to mark it as unstable anyway just to be safe, since it's more correct for docs anyway.
…nathanBrouwer Rollup of 14 pull requests Successful merges: - rust-lang#162976 (fix quadratic naming of duplicate sidebar links) - rust-lang#161275 (Refactor `core::cmp::{smallest, largest}` & add `mir-opt` test) - rust-lang#163143 (cg_llvm: Use fewer FFI calls to check the target CPU's features) - rust-lang#163188 (Adjust for Arm64EC name mangling when checking for exported symbols) - rust-lang#163211 (`rustc_builtin_macros` cleanup, part 6) - rust-lang#161386 (Don't merge distinct impl candidates) - rust-lang#162942 (Remove `StashKey::AssociatedTypeSuggestion`) - rust-lang#163096 (Don't suggest `std::` rustfix paths in `#![no_std]` crates) - rust-lang#163110 (Mark `std::os::wasip2` with correct doc-cfgs, mark as unstable) - rust-lang#163185 (properly decrement available_depth on cycles and provisional cache hits) - rust-lang#163214 (revert r14 register names for arm) - rust-lang#163226 (miri subtree update) - rust-lang#163228 (Add regression test for trait predicate with escaping bounds) - rust-lang#163234 (`rustc_dump_symbol_name`: add demangling information as a note instead)
replace instances of NonNull::new(&mut x).expect("...") with NonNull::from_mut
The docs of new_unchecked recommend using from_mut if you want to convert a mut ref to a NonNull. So this should also be reflected in other documentation.
…=hanna-kruppe vexos: clear .bss from assembly On `target_os = "vexos"`, libstd is responsible for clearing the `.bss` section during runtime initialization. This PR moves that step from Rust (previously done via `core::ptr::write_bytes`) to some assembly that runs even earlier into execution. The previous approach was sketchy at best when considering soundness, because: - Pointer provenance (probably) makes this UB since `.bss` lives inside the bounds of the abstract machine and we'd be writing to memory that will eventually hold statics. I have no idea how this plays out in practice, especially because it's a linkerscript symbol which isn't an actual value. - `core::ptr::write_bytes` gets lowered to a memclr intrinsic, which may access `.bss` depending on how its [implemented](https://github.com/rust-lang/compiler-builtins/blob/7f5edc1fc0f7b736d9beb6f817650feac7247114/compiler-builtins/src/arm.rs#L248) in `compiler-rt`. - On debug profiles, UB precondition checks might cause problems depending on what's being asserted before the runtime environment is sane. Anyways, for peace-of-mind it's much better to do this from assembly. The compiler changes here are trivial, just a change to the linkerscript to ensure that `__bss_start` gets aligned to a 4-byte boundary.
…JohnTitor Updates the expect message library/core/src/time.rs updates the expect message in library/core/src/time.rs. Updated to show the expected state instead of what actually happened. rust-lang#159751
…they
Make `NonNull::{read,write}_volatile` unstably const.
rust-lang#159092 added `const` to the functions `read_volatile` and `write_volatile` for `core::ptr`, `*const T`, and `*mut T`. This PR expands that to `NonNull<T>`, under the same feature `const_volatile`.
Tracking issue: rust-lang#159094
cc @RalfJung
…larfonthey Stabilize `ptr::try_cast_aligned` Stablization PR for `pointer_try_cast_aligned` **FCP not accepted yet**. Tracking issue: rust-lang#141221
…rfonthey std: remove unnecessary sysctl caching on FreeBSD The `install_main_guard` function is only called once, so there is no use in caching the value returned from the `sysctlbyname`.
…rfonthey Don't rely on `Global` handing out dangling pointers This code is incorrect and will leak memory once the global allocator supports zero-sized allocations, since `Box` doesn't deallocate zero-sized layouts
…ibute, r=bushrat011899 Add documentation for the `crate_name` attribute Add documentation for the `crate_name` attribute <!-- homu-ignore:start --> Briefly introduces how the attribute works, and things to be careful of when using the attribute. Part of rust-lang#157604
Rollup of 4 pull requests Successful merges: - rust-lang#163434 (Add documentation for the `crate_name` attribute) - rust-lang#163917 (Re-enable extension of bool return values on x86_64) - rust-lang#163242 (Expose regular argument attributes in rustc_public) - rust-lang#164071 (cg_llvm: Avoid all remaining uses of `as_c_char_ptr`)
…a-kruppe Replace `Unique` in `Box` with a `(NonNull, PhantomData)` wrapper Follow-up to rust-lang#162804 See [zulip](https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Can.20we.20nuke.20.60Unique.60.3F/with/624141418). This is only the first step in actually refactoring `Box`, and is essentially just a rename. The layout of `Box` stays as-is for now, due to rust-lang#162850. Needs perf run
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
The nightly-2026-10-11 subtree merge committed conflict markers, so core failed to compile and took down every Kani, Flux, goto-transcoder and upstream_test job. Keep our safety import and contracts, and take upstream's TryFromIntError import and the const read_volatile and write_volatile signatures.
Upstream now returns self.ptr directly in current_memory instead of self.ptr.into(). Apply the same change to the verified and with-directives copies and refresh original/. Verified locally with VeriFast 26.10: 0 errors, refinement checks pass.
Flux 849ef7c targets nightly-2026-09-25 and cannot compile the 10-11 core (unknown type_id_* and abort_immediate intrinsics). Flux main 6769bb9c includes the 10-11 toolchain upgrade (flux-rs/flux#1811). That Flux also needs a newer fixpoint: with nightly-2026-07-20 every query fails with "failed to run fixpoint: expected value at line 1 column 1". No dated liquid-fixpoint release exists after 07-20, so use the rolling nightly release, which is what Flux's own CI installs. Local run: 485 checked, 35 constraints solved, same as main.
Kani Metrics on macOS panicked at typ.rs:777 compiling core's SVE intrinsics (svld3_u8 and friends): rustc lays out SVE tuple types with a single field offset, which codegen_struct_fields did not expect (kani#4963). kani#4964 handles those tuples.
feliperodri
enabled auto-merge
October 14, 2026 10:38
feliperodri
approved these changes
Oct 14, 2026
The Build JSON step has not run on main since the nightly-2026-09-25 sync, because Kani Metrics kept failing before it on the aarch64 SVE ICE. With that fixed, log_parser.py fails on three changes: - Autoharness now covers __rust_panic_cleanup, which panic_abort and panic_unwind both define at crate root, so the harness name is listed twice. Record one entry for both crates instead of asserting. - Since kani#4927, automatic harnesses of generic functions are named after their instantiation (IntoIter<i32, 2>), so 76 contracts no longer find their harness by function name. Fall back to matching with generic arguments erased, and warn instead of failing when that is not unique. - Since kani#4944, every line of a worker's output carries a Thread N: prefix and workers interleave. Regroup the lines into the old per-thread blocks before parsing. Checked against the ubuntu and macOS artifacts of run 38539119625: every harness run in the logs (1994 and 1991) is parsed with its result and time.
feliperodri
approved these changes
Oct 14, 2026
This branch has not been deployed
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 2026-09-25 (rust-lang/rust@f7575a9) to 2026-10-11 (rust-lang/rust@6f5da40) (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: ff9a924