Rollup of 9 pull requests #149119
Open
Rollup of 9 pull requests #149119
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
…in-branch Explain `bors try parent=<sha>` and replace uses of `master` with `main` in all relevant files
... inspired from downstream default branch name change
update mentions of default branch of rust-lang/rust
sembr implementing_new_features.md and improve it a bit
sembr stabilization_guide.md and improve it a bit
sembr implementing_new_features.md again
ci: avoid sembr getting rebuilt on every push
sembr sanitizers.md again
add missing " and -Zoffload=Enable flag
on s390x 128bit types have a smaller alignment then on x86[^1]. This leads to smaller structs and therefore the write_unaligned will write outside of the structs boundary. For now disable the tests on s390x. [^2] [^1]: s390x ELF ABI Table 1.1, Page 12 https://github.com/IBM/s390x-abi [^2]: rust-lang#149056 (comment) Co-authored-by: Ralf Jung <post@ralfj.de>
This is useful for allowing writing run-make tests that test rustdoc-json.
These types are Id's to a table stored in TLS, so using them from another tread will either panic, or give wrong results. Therefor, I've added a `ThreadLocalIndex` marker type, which ensures types arn't `Send`/`Sync`. This is a breaking change for users of the `rustc_public` crate. Zulip Discussion: https://rust-lang.zulipchat.com/#narrow/channel/320896-project-stable-mir/topic/WDYM.20.22should.20not.20.20be.20shared.20across.20threads.22/with/547374171
…esolution Historically, it's not been possible to robustly resolve a cross-crate item in rustdoc-json. If you had a `Id` that wasn't in `Crate::index` (because it was defined in a different crate), you could only look it up it `Crate::paths`. But there, you don't get the full information, only an `ItemSummary`. This tells you the `path` and the `crate_id`. But knowing the `crate_id` isn't enough to be able to build/find the rustdoc-json output with this item. It's only use is to get a `ExternalCrate` (via `Crate::external_crates`). But that only tells you the `name` (as a string). This isn't enough to uniquely identify a crate, as there could be multiple versions/features [1] [2]. This was originally proposed to be solved via LukeMathWalker's `--orchestrator-id` proposal (https://www.github.com/rust-lang/compiler-team/issues/635). But that requires invasive changes to cargo/rustc. This PR instead implements Urgau's proposal to re-use the path to a crate's rmeta/rlib as a unique identifer. Callers can use that to determine which package it corresponds to in the language of the build-system above rustc. E.g. for cargo, `cargo rustdoc --message-format=json --output-format=json -Zunstable-options`). (Once you've found the right external crate's rustdoc-json output, you still need to resolve the path->id in that crate. But that's """just""" a matter of walking the module tree. We should probably still make that nicer (by, for example, allowing sharing `Id`s between rustdoc-json document), but that's a future concern) For some notes from RustWeek 2025, where this was designed, see https://hackmd.io/0jkdguobTnW7nXoGKAxfEQ [1]: https://www.github.com/rust-lang/compiler-team/issues/635#issue-1714254865 § Problem [2]: https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/Identifying.20external.20crates.20in.20Rustdoc.20JSON/with/352701211
Add doc for va_list APIs I observed that [PR146521](rust-lang#146521) submitted two weeks ago resolved some documentation issues related to `VaListImpl`, similar to the previous [PR136969](rust-lang#136969). This PR specifically adds requirements about argument availability for `VaListImpl::arg`, and also adds safety descriptions to the three associated intrinsic APIs.
alloc: fix `Debug` implementation of `ExtractIf` I noticed this while reviewing rust-lang#141032. Calling `get` on the inner `Vec` never returns `Some` as the `Vec`'s length is temporarily set to zero while the `ExtractIf` exists.
…vidtwco,tgross35 Add support for hexagon-unknown-qurt target MCP: rust-lang/compiler-team#919 Fixes rust-lang#148982.
…celinval rustc_public: Make Id types !Send / !Sync These types are Id's to a table stored in TLS, so using them from another tread will either panic, or give wrong results. Therefor, I've added a ~~`ReferencesTls`~~`ThreadLocalIndex` marker type, which ensures types arn't `Send`/`Sync`. This is a breaking change for users of the `rustc_public` crate. ~~It also changes how `DefId` and similar are `Serialize`d. It would be possible to preserve the old behavior if that's needed, but I couldn't see any tests for these.~~ EDIT: Not anymore: rust-lang#148261 (comment) Zulip Discussion: https://rust-lang.zulipchat.com/#narrow/channel/320896-project-stable-mir/topic/WDYM.20.22should.20not.20.20be.20shared.20across.20threads.22/with/547374171
…nsized, r=bjorn3 ignore unsized types in mips64 and sparc64 callconvs Non-rustic calling conventions should not make up an ABI for unsized types (cc rust-lang#148302). The vast majority of our callconv implementations already ignore unsized types, `sparc64` and `mips64` I guess were missed. r? ```@bjorn3```
…-out-of-spite-does-it-matter, r=GuillaumeGomez rustdoc-json: add rlib path to ExternalCrate to enable robust crate resolution Historically, it's not been possible to robustly resolve a cross-crate item in rustdoc-json. If you had a `Id` that wasn't in `Crate::index` (because it was defined in a different crate), you could only look it up it `Crate::paths`. But there, you don't get the full information, only an `ItemSummary`. This tells you the `path` and the `crate_id`. But knowing the `crate_id` isn't enough to be able to build/find the rustdoc-json output with this item. It's only use is to get a `ExternalCrate` (via `Crate::external_crates`). But that only tells you the `name` (as a string). This isn't enough to uniquely identify a crate, as there could be multiple versions/features [^1] [^2]. This was originally proposed to be solved via `@LukeMathWalker's` `--orchestrator-id` proposal (rust-lang/compiler-team#635). But that requires invasive changes to cargo/rustc. This PR instead implements `@Urgau's` proposal to re-use the path to a crate's rmeta/rlib as a unique identifer. Callers can use that to determine which package it corresponds to in the language of the build-system above rustc. E.g. for cargo, `cargo rustdoc --message-format=json --output-format=json -Zunstable-options`). (Once you've found the right external crate's rustdoc-json output, you still need to resolve the path->id in that crate. But that's """just""" a matter of walking the module tree. We should probably still make that nicer (by, for example, allowing sharing `Id`s between rustdoc-json document), but that's a future concern) For some notes from RustWeek 2025, where this was designed, see https://hackmd.io/0jkdguobTnW7nXoGKAxfEQ CC `@obi1kenobi` (who wants this for cargo-semver-checks [^3]), `@epage` (who's conversations on what and wasn't possible with cargo informed taking this approach to solve this problem) r? `@GuillaumeGomez` ## TODO: - [x] Docs: [Done](https://github.com/rust-lang/rust/compare/e4cdd0c24a994fed354081b5f907680a11f2ddc5..457ed4edb184997d5d6f879c6a220bc4d69ff6fd) - [x] Tests: [Done](https://github.com/rust-lang/rust/compare/2e1b954dc52bf7e5a6e9311394df760db37d383f..4d00c1a7ee5e03d1e78801cc01a85dac08ab603b) [^1]: rust-lang/compiler-team#635 (comment) § Problem [^2]: https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/Identifying.20external.20crates.20in.20Rustdoc.20JSON/with/352701211 [^3]: obi1kenobi/cargo-semver-checks#638
…rite, r=RalfJung
fix the fragment_in_dst_padding_gets_overwritten test on s390x
on s390x 128bit types have a smaller alignment then on x86[^1]. This leads to smaller structs (24 instead of 32 bytes) and therefore the write_unaligned will write outside of the structs boundary.
To fix the test, change the trailing u32 into a u8. This will generate 7 trailing padding bytes on s390x and 15 on x86_64. Also change the start of the garbage data so it will span over x,y and padding:
```
s390x: XXXXXXXXXXXXXXXXY-------
x86_64: XXXXXXXXXXXXXXXXY---------------
GGGGGGGG
```
[^1]: s390x ELF ABI Table 1.1, Page 12 https://github.com/IBM/s390x-abi
rustc-dev-guide subtree update Subtree update of `rustc-dev-guide` to rust-lang/rustc-dev-guide@61ad195. Created using https://github.com/rust-lang/josh-sync. r? ```@ghost```
…r=Noratrieb [AIX][ppc64le-linux-gnu] Add Amy Kwan to target maintainers Amy has effectively been helping to maintain these Power targets for a while, so add her to the maintainers list.
rustbot
added
A-run-make
Member
Author
|
Rollup of everything. @bors r+ rollup=never p=5 |
Collaborator
bors
added
S-waiting-on-bors
Collaborator
bors
added a commit
that referenced
this pull request
Nov 20, 2025
Rollup of 9 pull requests Successful merges: - #146925 (Add doc for va_list APIs) - #147035 (alloc: fix `Debug` implementation of `ExtractIf`) - #147173 (Add support for hexagon-unknown-qurt target) - #148261 (rustc_public: Make Id types !Send / !Sync) - #149041 (ignore unsized types in mips64 and sparc64 callconvs) - #149043 ( rustdoc-json: add rlib path to ExternalCrate to enable robust crate resolution) - #149056 (fix the fragment_in_dst_padding_gets_overwritten test on s390x) - #149095 (rustc-dev-guide subtree update) - #149108 ([AIX][ppc64le-linux-gnu] Add Amy Kwan to target maintainers) r? `@ghost` `@rustbot` modify labels: rollup
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
13 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:
Debugimplementation ofExtractIf#147035 (alloc: fixDebugimplementation ofExtractIf)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup