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.
Fixesrust-lang/rust#146912 as far as I can tell (the test passes.)
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 https://github.com/rust-lang/rust/issues/145995.
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`
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/rust#145967 by including spans in layout errors for all ADTs.
r? ``@RalfJung``
cc ``@workingjubilee`` ``@programmerjake``
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/rust#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](https://github.com/rust-lang/rust/pull/131530#issuecomment-2432856841).
## 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/rust#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](c6c5bad11e/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.
Do not materialise X in [X; 0] when X is unsizing a const
Fixrust-lang/rust#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!
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/).
library: std: sys: pal: uefi: Add some comments
I seemed to have forgotten that since I am using GET_PROTOCOL attribute for the std usecases, I did not need to close the protocols explicitly. So adding these comments as a note to future self not to waste time on the same thing again.
Make missed precondition-free float intrinsics safe
So, in my defence, these were both separated out from the other intrinsics in the file *and* had a different safety comment in the stable versions, so, I didn't notice them before. But, in my offence, the entire reason I did the previous PR was because I was using them for SIMD intrinsic fallbacks, and `fabs` is needed for those too, so, I don't really have an excuse.
Extra follow-up to rust-lang/rust#146683.
r? ```@RalfJung``` who reviewed the previous one
These don't appear to be used anywhere outside of the standard locations, at least.
fix 2 borrowck issues
fixes https://github.com/rust-lang/rust/issues/146467 cc ``@amandasystems``
our understanding here is as follows: region constraints from computing implied bounds gets `ConstraintCategory::Internal`. If there's a higher-ranked subtyping errors while computing implied bounds we then ended up with only `ConstraintCategory::Internal` and `ConstraintCategory::OutlivesUnnameablePlaceholder(_)` constraints.
The path was something like
- `'placeholderU2: 'placeholderU1` (`Internal`)
- `'placeholderU1: 'static` (`OutlivesUnnameablePlaceholder('placeholderU2)`)
It's generally somewhat subtle here as ideally relating placeholders doesn't introduce `'static` constraints. Relating the placeholders themselves will always error regardless, cc https://github.com/rust-lang/rust/pull/142623.
---
separately fixes https://github.com/rust-lang/rust/pull/145925#issuecomment-3303733357 by updating the location for deferred closure requirements inside of promoteds. I am not updating their category as doing so is 1) effort and 2) imo actually undesirable 🤔 see the comments in `TypeChecker::check_promoted` cc ``@lqd``
r? lqd
I seemed to have forgotten that since I am using GET_PROTOCOL attribute
for the std usecases, I did not need to close the protocols explicitly.
So adding these comments as a note to future self not to waste time on
the same thing again.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Fix a crash/mislex when more than one frontmatter closing possibility is considered
When the less fortunate recovery path for frontmatters are taken, if the lexer considers more than one possible frontmatter closing possibility, the current index is entirely mis-tracked and can result in bump_bytes landing in the middle of a multichar unicode character.
This fixes it by tracking the actual base index and updating it as it considers additional closing possibilities.
fixesrust-lang/rust#146847
Update books
## rust-lang/book
1 commits in 3e9dc46aa563ca0c53ec826c41b05f10c5915925..33f1af40cc44dde7e3e892f7a508e6f427d2cbc6
2025-09-15 16:10:14 UTC to 2025-09-15 16:10:14 UTC
- Release trpl 0.3 (rust-lang/book#4505)
## rust-lang/reference
9 commits in b3ce60628c6f55ab8ff3dba9f3d20203df1c0dee..cc7247d8dfaef4c39000bb12c55c32ba5b5ba976
2025-09-20 10:26:26 UTC to 2025-09-08 18:07:29 UTC
- Document temporary scoping for destructuring assignments (rust-lang/reference#1992)
- Specify lifetime extension of `pin!` and `format_args!` arguments (rust-lang/reference#1980)
- update for more ABIs supporting c-variadics (rust-lang/reference#1936)
- Fix incorrect span tag (rust-lang/reference#1995)
- Remove strike attribute (rust-lang/reference#1997)
- Specify the target limits for target-specific ABIs (rust-lang/reference#2000)
- Remove tuple index carve out (rust-lang/reference#1966)
- Enable folding of chapter listing in navigation sidebar (rust-lang/reference#1988)
- Add support to grammar for single line comments (rust-lang/reference#1993)
## rust-lang/rust-by-example
1 commits in dd26bc8e726dc2e73534c8972d4dccd1bed7495f..2c9b490d70e535cf166bf17feba59e594579843f
2025-09-18 22:28:52 UTC to 2025-09-18 22:28:52 UTC
- Update unit testing output for additional test (rust-lang/rust-by-example#1958)
