Skip to content

Rollup of 7 pull requests - #149369

Closed
Zalathar wants to merge 16 commits into
rust-lang:mainfrom
Zalathar:rollup-ouerfur
Closed

Rollup of 7 pull requests#149369
Zalathar wants to merge 16 commits into
rust-lang:mainfrom
Zalathar:rollup-ouerfur

Conversation

@Zalathar

@ZalatharZalathar commented Nov 27, 2025

Copy link
Copy Markdown
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

jdonszelmannand others added 16 commits November 24, 2025 15:04
Relocate issues/issue-51154.rs to closures/box-generic-closure.rs
Relocate issues/issue-51515.rs to
borrowck/assignment-to-immutable-ref.rs
Relocate issues/issue-53348.rs to mismatched_types/deref-string-assign.rs
Relocate issues/issue-52717.rs to
pattern/match-enum-struct-variant-field-missing.rs
Relocate issues/issue-53300.rs to
type/cannot-find-wrapper-with-impl-trait.rs
…on, r=Mark-Simulacrum
implement `Iterator::{exactly_one, collect_array}`
As per rust-lang#149266
…ulacrum
Suggest _bytes versions of endian-converting methods
As pointed out [in this article](https://purplesyringa.moe/blog/ntoh-hton-is-a-bad-api/), the `int.to_be()`/`int.to_le()` functions are technically returning a wrong type, because endian-specific representations of integers and Rust's always-native-endian integers are different things.
I wanted to make the docs state more directly that byte swapping will result in the type having a "wrong" value, but I wasn't sure whether to delve into the special case of palindrome-like values (`0x12343412`) not changing.
I've updated the docs to suggest `{to,from}_[lb]e_bytes()` instead. These methods use `[u8; _]` for endian-specific representations, which is a different type than the native-endian `u16`/`u32`/`u64`, and this is a type-safety improvement.
…eGomez
fix rustdoc search says “Consider searching for "null" instead.” rust-lang#149324fixrust-lang#149324
Now builds the “generic parameter” correction banner from discrete sentence fragments and appends the “Consider searching …” clause only when query.proposeCorrectionTo is non-null, so the UI no longer renders null as the suggested type.
Adds a PARSED section with two queries: one typo (Result<SomeTraiz>) that still produces a concrete suggestion and one fully unknown type (Result<NoSuchTrait>) that leaves proposeCorrectionTo null.
Tidying up UI tests [3/N]
> [!NOTE]
> Intermediate commits are intended to help review, but will be squashed prior to merge.
part of rust-lang#133895
Relocate 5 tests from tests/ui/issues
…3557, r=Mark-Simulacrum
Document that `build.description` affects symbol mangling and crate IDs
Addresses issue rust-lang#103557
Adds warning to `bootstrap.example.toml` explaining that changing build.description affects crate IDs and symbol name mangling, which makes compiled artifacts incompatible across different values.
As ``@Mark-Simulacrum`` points out, "if you're building with different settings, we really can't guarantee compatibility in any nice way." This documentation attempts to make that clear. This is my first contribution here, so any feedback would be greatly appreciated!
…Simulacrum
Enable CI download for windows-gnullvm
This works now!
@rustbotrustbot added A-rustdoc-search Area: Rustdoc's search feature S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-clippy Relevant to the Clippy team. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rust-analyzer Relevant to the rust-analyzer team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. rollup A PR which is a rollup labels Nov 27, 2025
@Zalathar
Zalathar deleted the rollup-ouerfur branch November 27, 2025 04:47
@rustbotrustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 27, 2025
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-rustdoc-searchArea: Rustdoc's search featurerollupA PR which is a rollupT-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)T-clippyRelevant to the Clippy team.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.T-libsRelevant to the library team, which will review and decide on the PR/issue.T-rust-analyzerRelevant to the rust-analyzer team, which will review and decide on the PR/issue.T-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.T-rustdoc-frontendRelevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants

@Zalathar@rustbot@jdonszelmann@kornelski@asukaminato0721@m-ou-se@reddevilmidzy@amahuli03@mati865