Skip to content

Rollup of 6 pull requests - #160367

Closed
jhpratt wants to merge 22 commits into
rust-lang:mainfrom
jhpratt:rollup-dPUDR1v
Closed

Rollup of 6 pull requests#160367
jhpratt wants to merge 22 commits into
rust-lang:mainfrom
jhpratt:rollup-dPUDR1v

Conversation

@jhpratt

@jhpratt jhpratt commented Aug 2, 2026

Copy link
Copy Markdown
Member

Successful merges:

r? @ghost

Create a similar rollup

folkertdev and others added 22 commits July 18, 2026 16:50
…r=clarfonthey

Move `std::io` tests to `alloctests` & add prelude

ACP: rust-lang/libs-team#755
Tracking issue: rust-lang#154046
~~Blocked on: rust-lang#158548~~

## Description

* Moves tests out of `std::io` into `alloctests` now that the relevant items are fully available from `alloc::io`.
* Adds documentation to `alloc::io`
* Adds prelude modules to `core::io` and `alloc::io`.

---

## Notes

* No AI tooling of any kind was used during the creation of this PR.
… r=Amanieu

Stabilize passing 128-bit integers via vector registers with `asm!` on x86

tracking issue: rust-lang#133416
reference PR: rust-lang/reference#2313

# Stabilization report

## Summary

Stabilize passing 128-bit integers via vector registers with `asm!` on x86 and x86_64:

```rust
// Use 128-bit integers with vector registers.
let mut v = 0u128;

asm!("/* {:x} */", in(xmm_reg) v);
asm!("/* {:x} */", out(xmm_reg) v);

asm!("/* {:y} */", in(ymm_reg) v);
asm!("/* {:y} */", out(ymm_reg) v);

asm!("/* {:z} */", in(zmm_reg) v);
asm!("/* {:z} */", out(zmm_reg) v);
```

32-bit and 64-bit integer types can already be passed via vector registers. LLVM has supported 128-bit integers since 2019, see llvm/llvm-project#42502, so `rustc` not supporting them seems like an oversight.

This feature is part of [`asm_experimental_reg`](rust-lang#133416). We're not stabilizing that feature as a whole, but only pull out part of it.

## History

- rust-lang#151059

## Open questions

None.

r? Amanieu
Specialize `advance_by` method of `Fuse`

`advance_by` is used a lot internally so it seems important to specialize it.
…htriplett

Allow only implementing `Read::read_buf`

This PR allows users to only implement `Read::read_buf`, without the need for implementing `Read::read`. `rustc_must_implement_one_of` annotation ensures that **at least** one of the methods is implemented, so that the default impls don't create infinite recursion.

Note that `Read::read_buf` is unstable, so this doesn't change anything on stable, there you still need to implement `Read::read`, since you can't implement `Read::read_buf`. Thus, we don't expose `rustc_must_implement_one_of` to stable.

r? @thomcc
allocations are allowed to grow (but not shrink)

This got permitted on the LLVM side about a year ago (llvm/llvm-project#141338), but didn't require any code changes since LLVM's optimizations were already compatible with growing allocations. That said, LLVM assumes that allocations created via operations it recognizes (e.g. `malloc`, `alloca`, or the Rust global allocator operations) never change their size, so we have to exclude that case.

This resolves a part of rust-lang/unsafe-code-guidelines#430.

It may seem strange that allocations can grow but not shrink, but we did have multiple users show up in #t-opsem with exactly that request. Cc @nhusung @foonathan; see [here](https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/Shrinking.20allocations.20in-place/near/612181257) and [here](https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/Shrinking.20allocations.20in-place/near/612191402) for some details about their use-cases.

Cc @rust-lang/opsem @rust-lang/lang
…parent-map, r=fee1-dead

fix: Do not stop `visible_parent_map` breadth-first search reaching children of `#[doc(hidden)]` modules

The `visible_parent_map` query misses putting the child items of `#[doc(hidden)]` modules into the queue, resulting in the breadth-first search missing them entirely. This results in inconsistent path printing behavior affecting diagnostics: namely that re-exports nested deeply within `#[doc(hidden)]` modules are not considered as a possible fallback path. See the linked issue (rust-lang#159880) for more details and an example of how this manifests in diagnostics.

This PR makes sure that `#[doc(hidden)]` parents in the fallback map are still searched as part of the breadth-first search.

Fixes rust-lang#159880.

The two tests for this change are based on the inconsistent diagnostics shown in the issue:
* `tests/ui/suggestions/suggest-path-through-direct-dep-crate/hidden-reexport-of-transitive-dep-item.rs` captures the current, expected behavior in the already working base case where the hidden module is still recorded in the fallback map;
* `tests/ui/suggestions/suggest-path-through-direct-dep-crate/hidden-reexport-of-nested-transitive-dep-item.rs` is a regression test for the breadth-first search covering nested children of `#[doc(hidden)]` modules to populate the fallback map by testing whether the diagnostic prefers the hidden but accessible path through the direct dependency crate.

Related PRs/issues:
* rust-lang#87349
* rust-lang#153477
@rust-bors rust-bors Bot added the rollup A PR which is a rollup label Aug 2, 2026
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. 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-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. labels Aug 2, 2026
@jhpratt

jhpratt commented Aug 2, 2026

Copy link
Copy Markdown
Member Author

@bors r+ rollup=never p=5

@rust-bors

rust-bors Bot commented Aug 2, 2026

Copy link
Copy Markdown
Contributor

📌 Commit c43b1f6 has been approved by jhpratt

It is now in the queue for this repository.

@rust-bors rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 2, 2026
@rust-bors

This comment has been minimized.

rust-bors Bot pushed a commit that referenced this pull request Aug 2, 2026
Rollup of 6 pull requests

Successful merges:

 - #156527 (Move `std::io` tests to `alloctests` & add prelude)
 - #159525 (Stabilize passing 128-bit integers via vector registers with `asm!` on x86)
 - #160342 (Specialize `advance_by` method of `Fuse`)
 - #106643 (Allow only implementing `Read::read_buf`)
 - #159729 (allocations are allowed to grow (but not shrink))
 - #159881 (fix: Do not stop `visible_parent_map` breadth-first search reaching children of `#[doc(hidden)]` modules)
@rust-log-analyzer

Copy link
Copy Markdown
Collaborator

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)
.............................................      (145/145)

======== tests/rustdoc-gui/item-decl-comment-highlighting.goml ========

[ERROR] line 67
    at `tests/rustdoc-gui/item-decl-comment-highlighting.goml` line 20
    at `tests/rustdoc-gui/item-decl-comment-highlighting.goml` line 10: TimeoutError: Navigation timeout of 30000 ms exceeded: for command `go-to: |url|`
    at <file:///checkout/obj/build/x86_64-unknown-linux-gnu/test/rustdoc-gui/doc/proc_macro_test/derive.HelperAttr.html>


<= doc-ui tests done: 144 succeeded, 1 failed, 0 filtered out

Error: ()

@rust-bors rust-bors Bot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Aug 2, 2026
@rust-bors

rust-bors Bot commented Aug 2, 2026

Copy link
Copy Markdown
Contributor

💔 Test for b85d881 failed: CI. Failed job:

@JonathanBrouwer

Copy link
Copy Markdown
Contributor

Spurious

@rust-bors rust-bors Bot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Aug 2, 2026
@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 2, 2026
@rust-bors

rust-bors Bot commented Aug 2, 2026

Copy link
Copy Markdown
Contributor

This pull request was unapproved due to being closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

rollup A PR which is a rollup S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. 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-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.

Projects

None yet

Development

Successfully merging this pull request may close these issues.