Rollup of 11 pull requests#153303
Closed
JonathanBrouwer wants to merge 39 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.
`rustc_with_all_queries` currently provides information about all queries. Also, a caller can provide an ad hoc list of extra non-queries. This is used by `define_queries` for non-query dep kinds: `Null`, `Red`, etc. This is pretty hacky. This commit changes `rustc_with_all_queries` so that the non-queries information is available to all callers. (Some callers ignore the non-query information.) This is done by adding `non_query` entries to the primary list of queries in `rustc_queries!`.
Currently `define_dep_nodes` produces a macro `make_dep_kind_array` that encodes the names of non-queries followed by queries. This macro is used by `make_dep_kind_vtables` to make the full array of vtables, by referring to vtable constructor functions that are put into `mod _dep_kind_vtable_ctors`. Pretty weird! This commit takes advantage of the previous commit's changes to `rustc_with_all_queries`, which makes both query and non-query information available. A new call to `rustc_with_all_queries` is used to construct the vtable array. (This moves some dep_kind_vtable code from `plumbing.rs` to `dep_kind_vtables.rs`, which is good.) It's straightforward now with iterator chaining, and `mod _dep_kind_vtable_ctors` is no longer needed.
"i.e." is short for the Latin "id est" and thus both letters should be followed by periods.
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.
Hermit does not yet support spawning processes.
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
rustbot
added
A-meta
Contributor
Author
|
@bors r+ rollup=never p=5 |
Contributor
rust-bors
bot
added
S-waiting-on-bors
Contributor
|
⌛ Testing commit 74250ed with merge 53a4aef... Workflow: https://github.com/rust-lang/rust/actions/runs/22591029555 |
rust-bors bot
pushed a commit
that referenced
this pull request
Mar 2, 2026
…uwer Rollup of 11 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`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - #153293 (library: std: process: skip tests on Hermit) - #153301 (Do not ping kobzol on rustc-dev-guide changes)
rust-bors
bot
added
S-waiting-on-author
Contributor
|
PR #149328, which is a member of this rollup, was unapproved. Auto build cancelled due to unapproval. Cancelled workflows: |
rustbot
removed
the
S-waiting-on-author
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
12 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.
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>)rustc_with_all_queries!#153161 (Rejigrustc_with_all_queries!)unused_resultslint for tuples of "trivial" types #153191 ( don't emitunused_resultslint for tuples of "trivial" types )r? @ghost
Create a similar rollup