Rollup of 14 pull requests #147019
Merged
Rollup of 14 pull requests #147019
Conversation
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
- RawVecInner::grow_exact causes UB if called with len and additional arguments such that len + additional is less than the current capacity. Indeed, in that case it calls Allocator::grow with a new_layout that is smaller than old_layout, which violates a safety precondition. - All RawVecInner methods for resizing the buffer cause UB if called with an elem_layout different from the one used to initially allocate the buffer, because in that case Allocator::grow/shrink is called with an old_layout that does not fit the allocated block, which violates a safety precondition. - RawVecInner::current_memory might cause UB if called with an elem_layout different from the one used to initially allocate the buffer, because the unchecked_mul might overflow. - Furthermore, these methods cause UB if called with an elem_layout where the size is not a multiple of the alignment. This is because Layout::repeat is used (in layout_array) to compute the allocation's layout when allocating, which includes padding to ensure alignment of array elements, but simple multiplication is used (in current_memory) to compute the old allocation's layout when resizing or deallocating, which would cause the layout used to resize or deallocate to not fit the allocated block, which violates a safety precondition.
Emit `#[rustc_allocator]` etc. attributes on the functions generated by the `#[global_allocator]` macro, which will emit LLVM attributes like `"alloc-family"`. If the module with the global allocator participates in LTO, this ensures that the attributes typically emitted on the allocator declarations are not lost if the definition is imported.
LLVM change dfbd76bda01e removed separate remark support entirely, but it turns out we can just drop the parameter and everything appears to work fine. Fixes 146912 as far as I can tell (the test passes.) @rustbot label llvm-main
…monomorphization Unify zero-length and oversized SIMD errors
Co-authored-by: Lewis McClelland <lewis@lewismcclelland.me>
Signed-off-by: Ding Xiang Fei <dingxiangfei2009@protonmail.ch> Co-authored-by: Theemathas Chirananthavat <theemathas@gmail.com>
Co-authored-by: Ralf Jung <post@ralfj.de>
Although the examples below this list do imply that there's an impl of `ToSocketAddrs` for `&[SocketAddr]`, it's not actually noted in the list of default implementations.
On resource-constrained systems, it is vital to respect the value of build.jobs, in order to avoid overwhelming the available memory.
RawVecInner: add missing `unsafe` to unsafe fns Some (module-private) functions in `library/alloc/src/raw_vec/mod.rs` are unsafe (i.e. may cause UB when called from safe code) but are not marked `unsafe`. Specifically: - `RawVecInner::grow_exact` causes UB if called with `len` and `additional` arguments such that `len + additional` is less than the current capacity. Indeed, in that case it calls [Allocator::grow](https://doc.rust-lang.org/std/alloc/trait.Allocator.html#method.grow) with a `new_layout` that is smaller than `old_layout`, which violates a safety precondition. - The RawVecInner methods for resizing the buffer cause UB if called with an `elem_layout` different from the one used to initially allocate the buffer, because in that case `Allocator::grow` or `Allocator::shrink` are called with an `old_layout` that does not *fit* the allocated block, which violates a safety precondition. - `RawVecInner::current_memory` might cause UB if called with an `elem_layout` different from the one used to initially allocate the buffer, because the `unchecked_mul` might overflow. - Furthermore, these methods cause UB if called with an `elem_layout` where the size is not a multiple of the alignment. This is because `Layout::repeat` is used (in `layout_array`) to compute the allocation's layout when allocating, which includes padding to ensure alignment of array elements, but simple multiplication is used (in `current_memory`) to compute the old allocation's layout when resizing or deallocating, which would cause the layout used to resize or deallocate to not *fit* the allocated block, which violates a safety precondition. I discovered these issues while performing formal verification of `library/alloc/src/raw_vec/mod.rs` per [Challenge 19](https://model-checking.github.io/verify-rust-std/challenges/0019-rawvec.html) of the [AWS Rust Standard Library Verification Contest](https://aws.amazon.com/blogs/opensource/verify-the-safety-of-the-rust-standard-library/).
…o-const, r=nnethercote Do not materialise X in [X; 0] when X is unsizing a const Fix rust-lang#143671 It turns out that MIR builder materialise `X` in `[X; 0]` into a temporary local when `X` is unsizing a `const`. This led to a confusing call to destructor of `X` when such a destructor is declared. [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=8dfc933af89efeb89c881bc77498ba63) This patch may miss out other cases that we should avoid materialisation in case of `[X; 0]`. Suggestions to include is most welcome!
Add `std` support for `armv7a-vex-v5` This PR adds standard library support for the VEX V5 Brain (`armv7a-vex-v5` target). It is more-or-less an updated version of the library-side work done in rust-lang#131530. This was a joint effort between me, `@lewisfm,` `@max-niederman,` `@Gavin-Niederman` and several other members of the [`vexide` project](https://github.com/vexide/). ## Background VEXos is a fairly unconventional operating system, with user code running in a restricted enviornment with regards to I/O capabilities and whatnot. As such, several OS-dependent APIs are unsupported or have partial support (such as `std::net`, `std::process`, and most of `std::thread`). A more comprehensive list of what does or doesn't work is outlined in the [updated target documentation](https://github.com/vexide/rust/blob/vex-std/src/doc/rustc/src/platform-support/armv7a-vex-v5.md). Despite these limitations, we believe that `libstd` support on this target still has value to users, especially given the popular use of this hardware for educational purposes. For some previous discussion on this matter, see [this comment](rust-lang#131530 (comment)). ## SDK Linkage VEXos doesn't really ship with an official `libc` or POSIX-style platform API (and though it does port newlib, these are stubbed on top of the underlying SDK). Instead, VEX provides their own SDK for calling platform APIs. Their official SDK is kept proprietary (with public headers), though open-source implementations exist. Following the precedent of the `armv6k-nintendo-3ds` team's work in rust-lang#95897, we've opted not to directly link `libstd` to any SDK with the expectation that users will provide their own with one of the following options: - [`vex-sdk-download`](https://github.com/vexide/vex-sdk/tree/main/packages/vex-sdk-download), which downloads an official proprietary SDK from VEX using a build script. - [`vex-sdk-jumptable`](https://crates.io/crates/vex-sdk-jumptable), which is a compatible, open-source reimplementation of the SDK using firmware jumps. - [`vex-sdk-pros`](https://github.com/vexide/vex-sdk/tree/main/packages/vex-sdk-pros), which uses the [PROS kernel](https://github.com/purduesigbots/pros) as a provider for SDK functions. - Linking their own implementation or stubbing the functions required by libstd. The `vex-sdk` crate used in the VEXos PAL provides `libc`-style FFI bindings for any compatible system library, so any of these options *should* work fine. A functional demo project using `vex-sdk-download` can be found [here](https://github.com/vexide/armv7a-vex-v5-demo/tree/main). ## Future Work This PR implements virtually everything we are currently able to implement given the current capabilities of the platform. The exception to this is file directory enumeration, though the implementation of that is sufficiently [gross enough](https://github.com/vexide/vexide/blob/c6c5bad11e035cf4e51d429dca7e427210185ed4/packages/vexide-core/src/fs/mod.rs#L987) to drive us away from supporting this officially. Additionally, I have a working branch implementing the `panic_unwind` runtime for this target, which is something that would be nice to see in the future, though given the volume of compiler changes i've deemed it out-of-scope for this PR.
…, r=lcnr,RalfJung Add an attribute to check the number of lanes in a SIMD vector after monomorphization Allows std::simd to drop the `LaneCount<N>: SupportedLaneCount` trait and maintain good error messages. Also, extends rust-lang#145967 by including spans in layout errors for all ADTs. r? ``@RalfJung`` cc ``@workingjubilee`` ``@programmerjake``
…,RalfJung unstably constify float mul_add methods Tracking issue: rust-lang#146724 r? `@tgross35`
f16_f128: enable some more tests in Miri For some reason, a bunch of tests were disabled in Miri that don't use any fancy intrinsics. Let's enable them. I verified this with `./x miri library/core --no-doc -- float`. r? `@tgross35`
…cote Add attributes for #[global_allocator] functions Emit `#[rustc_allocator]` etc. attributes on the functions generated by the `#[global_allocator]` macro, which will emit LLVM attributes like `"alloc-family"`. If the module with the global allocator participates in LTO, this ensures that the attributes typically emitted on the allocator declarations are not lost if the definition is imported. There is a similar issue when the allocator shim is used, but I've opted not to fix that case in this PR, because doing that cleanly is somewhat gnarly. Related to rust-lang#145995.
… r=nikic llvm: update remarks support on LLVM 22 LLVM change dfbd76bda01e removed separate remark support entirely, but it turns out we can just drop the parameter and everything appears to work fine. Fixes rust-lang#146912 as far as I can tell (the test passes.)
…=bjorn3 Remove erroneous normalization step in `tests/run-make/linker-warning` Fixes rust-lang#146977. r? bjorn3 or reassign
…leanup, r=jdonszelmann Small string formatting cleanup This PR is mostly useless. I was going through this file, saw that and corrected it. That's pretty much it. Feel free to close it if it's a bother.
5100
…oss35 Explicitly note `&[SocketAddr]` impl of `ToSocketAddrs` Although the examples below this list do imply that there's an impl of `ToSocketAddrs` for `&[SocketAddr]`, it's not actually noted in the list of default implementations.
bootstrap.py: Respect build.jobs while building bootstrap tool On resource-constrained systems, it is vital to respect the value of build.jobs, in order to avoid overwhelming the available memory.
|
Queue is mildly backed-up, so let's do some early try jobs. @bors try jobs=x86_64-msvc-1,test-various,armhf-gnu,aarch64-apple |
This comment has been minimized.
This comment has been minimized.
rust-bors bot
added a commit
that referenced
this pull request
Sep 25, 2025
Rollup of 14 pull requests try-job: x86_64-msvc-1 try-job: test-various try-job: armhf-gnu try-job: aarch64-apple
|
☀️ Test successful - checks-actions |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 7cfd7d3 (parent) -> 6f34f4e (this PR) Test differencesShow 510 test diffsStage 0
Stage 1
Stage 2
Additionally, 419 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 6f34f4ee074ce0affc7bbf4e2c835f66cd576f13 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
📌 Perf builds for each rolled up PR:
previous master: 7cfd7d328b In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Sep 25, 2025
|
Finished benchmarking commit (6f34f4e): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -2.3%, secondary 0.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.7%, secondary 0.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.0%, secondary 0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 469.935s -> 471.619s (0.36%) |
This was referenced Sep 25, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Successful merges:
unsafeto unsafe fns #145067 (RawVecInner: add missingunsafeto unsafe fns)stdsupport forarmv7a-vex-v5#145973 (Addstdsupport forarmv7a-vex-v5)tests/run-make/linker-warning#146982 (Remove erroneous normalization step intests/run-make/linker-warning)&[SocketAddr]impl ofToSocketAddrs#147007 (Explicitly note&[SocketAddr]impl ofToSocketAddrs)--doctest-build-arg#147013 (rustdoc: Fix documentation for--doctest-build-arg)LLVMDisposeTargetMachine#147015 (UseLLVMDisposeTargetMachine)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup