Rollup of 5 pull requests#153296
Closed
JonathanBrouwer wants to merge 23 commits intorust-lang:mainfrom
Closed
Conversation
This is a third attempt at implementing adding Allocator support to the std lib's `String`. Still stuck on the same issue with type inference failing on the newly generic `String<A>`, but I opted to do even less than the previous WIP work, and have added no new functions (`String<A>` can be constructed via `Vec<u8, A>` or `Box<str, A>`), and have moved only the struct definition to its own mod to make rebasing a bit easier if/when main changes underneath me.
This adds a diagnostic name `string_in_global` so that clippy can easily check for the alloc::string::String type alias.
added some code in linkchecker to check the generic::String docs when trying to resolve links to alloc::string::String type alias. There's some lazy-loading that the browser does, but linkchecker doesn't, so maybe some general-purpose solution would be better, but this seemed better than a big list of exceptions.
Yes, you could just use `unsafe { from_utf8_unchecked }``, but people get
antsy about `unsafe`, so add some Vec ctor/dtor equivalents.
the links are changed in the original source, so not sure why the html being checked in CI still has them, maybe it checks docs from `main` as well, but if so, wouldn't `struct.String.html` still exist? Truly a pickle, but I'll add these exceptions and a note.
The manual `DynSend` implementation for `AtomicPtr` blocks the auto-implementation for other atomic primitives since they forward to the same `Atomic<T>` type now. This breakage cannot occur in user code as it depends on `DynSend` being a custom auto-trait.
... and remove some unused diagnostic items.
and in particular for naked functions in that scenario
The uwtable attribute does not get emitted on targets that don't have unwinding tables, such as x86_64-unknown-hermit.
add tests for thumb interworking fixes rust-lang#151946 thumb programs (using a 16-bit instruction encoding) can call arm (32-bit instruction encoding) code. Doing so requires switching from thumb mode to arm mode, executing, then switching back. Test that this happens correctly, in particular for naked functions. cc @thejpster can you confirm the output looks good here and that we're testing all of the relevant things r? jieyouxu because this is doing some interesting things testing-wise I believe that we need run-make here because we need to look at the assembly after the linker has run. It will correct calls from thumb to arm: depending on the thumb version this either uses a special instruction or inserts a call to a thunk that handles switching between thumb and arm mode.
Add `String<A>` type with custom allocator parameter This change is part of the `allocator_api` feature set [rust-lang#32838](rust-lang#32838) (also see [wg-allocators roadmap] or [libs-team ACP]). The previous attempts at adding an allocator parameter to string are at [rust-lang#101551], and [rust-lang#79500] (I think those authors should get much of the credit here, I am re-writing what they worked out in those threads). ## workaround There is a type inference ambiguity introduced when adding a generic parameter to a type which previously had none, even when that parameter has a default value (more details in [rust-lang#98931]). I've done the same [workaround] as [rust-lang#101551], which is to make `alloc::string::String` a type alias to `String<Global>`, but I've arranged the modules a bit differently to make rebase/merges a bit easier. This workaround unfortunately changes the type name of the `String` language item, and that would be user-facing in error or diagnostic output. I understand from [this comment](rust-lang#101551 (comment)) that this change is acceptable. ## changes to existing API Most of the methods on the original `String` have been implemented for the generic version instead. I don't foresee anything more moving from `String<Global>` to `String<A>`, as the remaining methods are all constructors which implicitly use the `Global` allocator. There are three general types of changes: 1. methods which don't allocate: here we just change `impl Foo for String` to `impl<A: Allocator> Foo for String<A>` 2. converting to/from other allocator generic types like `Vec<u8, A>` and `Box<str, A>`: here we can use the existing allocator from those types. 3. methods which clone from some other type with an allocator: here it's ambiguous whether the end result should be `String<A>`, `String<Global>`, or `String<impl Allocator + Default>`, etc; in general I try to leave these out of this change, but where some analogous change was made to `Vec<T, A>` I follow that. ## new methods Some methods have been added to `String<A>` which are not strictly necessary to land this change, but are considered helpful enough to users, and close enough to existing precedent in `Vec<T, A>`. Specifically, 4 new constructors (`new_in`, `with_capacity_in`, `try_with_capacity_in`, `from_raw_parts_in`), 1 destructor (`into_raw_parts_with_alloc`), and 1 getter (`allocator`). Technically, the updated `from_utf8_unchecked` should be sufficient for constructing, but we can add some safe constructors so users don't have to sully themselves. ## not implemented Variants of `from_utf{8,16}*` which internally allocate or use `Cow` have been punted on this PR, maybe a followup would make sense to either rewrite them, or add some `*_in` variant. [wg-allocators roadmap]: rust-lang/wg-allocators#7 [libs-team ACP]: rust-lang/libs-team#101 [workaround]: rust-lang#79499 (comment) [rust-lang#101551]: rust-lang#101551 [rust-lang#79500]: rust-lang#79500 [rust-lang#98931]: rust-lang#98931
…s, r=nikic Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs` It was discovered that the FileCheck tests when performing an `Option::or` operation on a slice was failing when tested on a big endian host. The compiler explorer link is here outlining the codegen output differences - https://rust.godbolt.org/z/qdE7d3G4f This MR relaxes the constraints for the `*slice_u8` variants of the test (by changing `CHECK-NEXT` to `CHECK-DAG`), whilst still maintaining the check for the necessary `or` logic. Huge thanks to @Gelbpunkt for identifying this issue! It has been confirmed that this fix passes on a big endian target now as well. Closes rust-lang#151718
…ratt core: make atomic primitives type aliases of `Atomic<T>` Tracking issue: rust-lang#130539 This makes `AtomicI32` and friends type aliases of `Atomic<T>` by encoding their alignment requirements via the use of an internal `Storage` associated type. This is also used to encode that `AtomicBool` store a `u8` internally. Modulo the `Send`/`Sync` implementations, this PR does not move any trait implementations, methods or associated functions – I'll leave that for another PR.
…onal, r=jieyouxu tests: codegen-llvm: vec-calloc: do not require the uwtable attribute The `uwtable` attribute does not get emitted on targets that don't have unwinding tables, such as `x86_64-unknown-hermit`.
Contributor
Author
|
@bors r+ rollup=never p=5 |
Contributor
Author
|
Trying commonly failed jobs |
Contributor
This comment has been minimized.
This comment has been minimized.
rust-bors bot
pushed a commit
that referenced
this pull request
Mar 2, 2026
Rollup of 5 pull requests try-job: test-various try-job: x86_64-gnu-aux try-job: x86_64-gnu-llvm-21-3 try-job: x86_64-msvc-1 try-job: aarch64-apple try-job: x86_64-mingw-1
This comment has been minimized.
This comment has been minimized.
rust-bors bot
pushed a commit
that referenced
this pull request
Mar 2, 2026
…uwer Rollup of 5 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #149328 (Add `String<A>` type with custom allocator parameter) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) Failed merges: - #151864 (Implement AST -> HIR generics propagation in delegation)
Contributor
Author
|
@bors r- cancel |
Contributor
|
📋 Only unclosed PRs can be unapproved. |
Contributor
Author
|
@bors cancel |
Contributor
|
❗ There is currently no auto build in progress on this PR. Hint: There is a pending try build on this PR. Maybe you meant to cancel it? You can do that using |
Contributor
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Contributor
|
PR #149328, which is a member of this rollup, was unapproved. |
Contributor
|
💔 Test for 1af80ea failed: CI. Failed jobs:
|
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
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:
String<A>type with custom allocator parameter #149328 (AddString<A>type with custom allocator parameter)multiple-option-or-permutations.rs#151780 (Updated slice tests to pass for big endian hosts formultiple-option-or-permutations.rs)Atomic<T>#153015 (core: make atomic primitives type aliases ofAtomic<T>)Failed merges:
r? @ghost
Create a similar rollup