Skip to content

Rollup of 13 pull requests - #160610

Closed
JonathanBrouwer wants to merge 33 commits into
rust-lang:mainfrom
JonathanBrouwer:rollup-NO42m91
Closed

Rollup of 13 pull requests#160610
JonathanBrouwer wants to merge 33 commits into
rust-lang:mainfrom
JonathanBrouwer:rollup-NO42m91

Conversation

@JonathanBrouwer

Copy link
Copy Markdown
Contributor

Successful merges:

r? @ghost

Create a similar rollup

jieyouxu and others added 30 commits August 3, 2026 13:26
…` jobs

The aarch64 macos runners seem to be consistently among the slowest
jobs, sometimes pushing our overall CI time to 4 hours on a bad run.
Let's try to split the jobs to keep the overall Merge CI time
manageable:

* `aarch64-apple` => `aarch64-apple-{1,2}`
* `aarch64-apple-macos-26` => `aarch64-apple-macos-26-{1,2}`
This method currently does two things: it applies the effect, and also
computes the edges. However:
- Three of the four call sites don't use the edges.
- Most analyses just return `terminator.edges()` unconditionally.

This commit separates the edge computation into a new method,
`get_terminator_edges()`. It defaults to `terminator.edges()`, which
means that most analyses don't need to define it. And now edges are only
obtained when they are needed (in `Forward::apply_effects_in_block`).
.. so that you don't need to import `TypeVisitable` in order to use it.
I used the `TypeVisitable` from `rustc_type_ir` and not
`rustc_middle::ty` because the macro is called inside `rustc_type_ir`
itself.
This is a cheaper alternative to `TyAndLayout::for_variant(_, idx).is_uninhabited()`
.. instead of hand-rolling our own
these are slightly distinct subsets of a platonic ideal borrowck.
Mitigation for [RUST-159429].

The recurring problem is that built-in attributes are treated
differently compared to ordinary prelude attributes, built-in
attributes, even while unstable, can name-collide with stable macro
re-exports of the same name (and proc-macro helper attributes of the
same name), which can break stable code. See [RUST-134964].

[RUST-159429]: rust-lang#159429
[RUST-134963]: rust-lang#134963
To account for the renamed `#[rustc_unroll]` attribute.
This stderr diff is a funny side-effect of renaming `#[unroll]` =>
`#[rustc_unroll]`, where the `#[rustc_unknown]` attribute name is just
similar enough edit distance wise to `#[rustc_unroll]` that
`#[rustc_unroll]` shows up as a plausible suggestion candidate, lol.
…, r=Mark-Simulacrum

Split `aarch64-apple{,-macos-26}` => `aarch64-apple{,-macos-26}-{1,2}` jobs

## Summary

The aarch64 macos runners seem to be consistently among the slowest jobs, sometimes pushing our overall CI time to 4 hours on a bad run. Let's try to split the jobs to keep the overall Merge CI time manageable:

* `aarch64-apple` => `aarch64-apple-{1,2}`
* `aarch64-apple-macos-26` => `aarch64-apple-macos-26-{1,2}`

Discussed in [#t-infra > GHA macos-26 slowness @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/GHA.20macos-26.20slowness/near/613771526).

### Some imprecise stats

Looking at [CI dashboard](https://p.datadoghq.com/sb/3a172e20-e9e1-11ed-80e3-da7ad0900002-b5f7bb7e08b664a06b08527da85f7e30?fromUser=true&refresh_mode=sliding&tpl_var_branch_name%5B0%5D=automation%2Fbors%2Fauto&tpl_var_env%5B0%5D=%2A&tpl_var_is_default_branch%5B0%5D=%2A&tpl_var_pipeline_name%5B0%5D=CI&tpl_var_provider_instance%5B0%5D=%2A&tpl_var_provider_name%5B0%5D=github&from_ts=1783056725849&to_ts=1785735125849&live=true) over past month (as of 2026-08-03):

| Job                    |   Median |      P95 | Run counts |
|------------------------|---------:|---------:|-----------:|
| aarch64-apple          | 2.94 hr  |  3.59 hr |       156  |
| aarch64-apple-macos-26 | 3.12 hr  |  3.59 hr |       148  |

The median seems *okay*, the `macos-26` job is on par median wise with `i686-msvc-1` and `dist-x86_64-linux`. It's the P95 that's more concerning, since `i686-msvc-1` P95 is the second-worst at `3.25` hr.

r? infra-ci

---

try-job: `aarch64-apple*`
…fallback-entry-check, r=oli-obk

fix: Check the fallback map before queueing child in `visible_parent_map` breadth-first search

The fix in rust-lang#159881 extended the `visible_parent_map` breadth-first search (BFS) to include items nested within "fallback" items, such as `#[doc(hidden)]` modules and re-exports. However, the fix resulted in fallback entries not being checked before enqueueing new items into the BFS, resulting in fallback items being explored in the BFS multiple times, once for each fallback parent, up until a non-fallback visible parent is found instead, if any.

This PR adds a check before new fallback items are recorded and the BFS queue is extended that ensures that the item has not already been searched through a fallback parent item.

Fixes the `libc` performance regression described in rust-lang#160439. (Fixes rust-lang#160439.)

Unfortunately, I could not think of a way to write a test case that covers the regression that this PR fixes, as it would require a massive crate with a very large number of "fallback" parents, and the test would be performance-based.
…, r=cjgillot

Split `apply_primary_terminator_effect`

It currently does two distinct things, and it's a bit nicer it they are separated. Details in individual commits.

r? @cjgillot
…im-hint, r=estebank

Suggest if-let chain continuation on unclosed delimiter

Meant to fix rust-lang#160550. When an unclosed brace-delimited block begins with && or ||, the "unclosed delimiter" error now points at that line, suggesting the user may have meant to continue an if-let chain.

- Records the leading `&&`/`||` span during lexing (in lex_token_tree_open_delim) and surfaces it in report_suspicious_mismatch_block.
- Adds a `tests/ui/parser` regression test.
Avoid the std DLL copy alongside rustc

This removes the extra the std DLL copy alongside rustc. Fixes rust-lang#131587.
Rename `#[unroll]` => `#[rustc_unroll]` to mitigate nameres ambiguity

## Summary

Mitigate rust-lang#159429 by renaming `#[unroll]` => `#[rustc_unroll]`.

Did not bother with a regression test, because a regression test would be hedging against an unknown attribute if `#[unroll]` later proceeds to get a different name.

Tracking issue for `#![feature(loop_hints)]`: rust-lang#156874.

## Rationale

Even while the crater-observed fallout seems to be relatively small, we'd like such nameres ambiguity breakages to be *deliberate* (read: T-lang FCP'd) rather than accidental (discovered through beta crater runs).

See discussions around [last week's compiler triage meeting](https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202026-07-23/near/612371735).

## Background context

The recurring problem is that built-in attributes are treated differently compared to ordinary prelude attributes, built-in attributes, even while unstable, can name-collide with stable macro re-exports of the same name (and proc-macro helper attributes of the same name), which can break stable code. See rust-lang#134964.

See also:

- rust-lang#133708
- rust-lang#53913 (comment)
- https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Name.20Res.3A.20questions.20on.20intended.20behavior/near/562001319
- rust-lang#143834 (comment)

## Prior Art

- For `#[align]`, breakage was more wide-spread, so we posted this same mitigation here: rust-lang#144080.
- For `#[sanitize]`, T-lang explicitly FCP'd the breakage stemming from renaming `#[no_sanitize]` (old name) to `#[sanitize]` (new name) that regressed a couple of crates: rust-lang#142681 (comment).

## Alternatives to this PR

Generally:

- We let it slide.
- T-lang FCP on `#[unroll]` breakage (in which case this PR should be closed).
- FCP another name (and associated breakages).
- (Hard) Fix the built-in attribute name resolution behavior.

I have no particular preference on the approaches myself, any of this PR and the alternatives seem fine so as long as the breakage is *deliberate* not accidental.
…ted, r=oli-obk

rustc_abi: Add `LayoutData::is_variant_uninhabited` method

This is a cheaper alternative to `TyAndLayout::for_variant(_, idx).is_uninhabited()`, which avoids the extra work done by `TyAndLayout::for_variant`.

EDIT: Let me expand on the motivation from this [comment](rust-lang#160398 (comment)):

`TyAndLayout::for_variant` is a curious API: the resulting layout doesn't represent a Rust type in the strict sense (not even `pattern_type!(Enum is Variant { .. })`; instead, it only describes the "variant-specific" fields, and fields shared between variants (e.g. the enum tag or coroutine captures) are entirely missing.

As such, I believe alternative APIs should be used instead to clarify intent, when possible. This PR deals with the simplest cases, and a future PR will add `TyAndLayout::variant_field(self, cx, variant_idx, field_idx)` to deal with the next-most common case of only needing a variant layout for field lookups.
Update error message in documentation comments

Fixes the `library/core/src/fmt/mod.rs` item in the rust-lang#159751 issue.
…nszelmann

Use `VisitorResult` helper macros

.. instead of hand-rolling our own

r? @jdonszelmann
Add regression test for array type recovery in generic arguments

Closes rust-lang#81097 adds a regression test. existing covrage was let position only
expand: Feature gate AST-based attribute macros on expressions and statements

Right now all of these macros happen to either be unstable or to produce errors when used on expressions and (non-item) statements, but it is safer to feature gate them anyway to avoid unexpected stability holes in the future, because all token-based macros are already feature-gated in these positions.
add a test showing polonius alpha is not a subset of datalog polonius

This adds a test showing how the datalog and alpha algorithms are not subsets of one another, and are slightly distinct subsets of a platonic ideal borrowck.

r? @jackh726
@rust-bors rust-bors Bot added the rollup A PR which is a rollup label Aug 6, 2026
@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-CI Area: Our Github Actions CI A-testsuite Area: The testsuite used to check the correctness of rustc 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-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-infra Relevant to the infrastructure 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. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) labels Aug 6, 2026
@JonathanBrouwer

Copy link
Copy Markdown
Contributor Author

@bors r+ p=5

Trying commonly failed jobs
@bors try jobs=dist-various-1,test-various,x86_64-gnu-aux,x86_64-gnu-llvm-21-3,x86_64-msvc-1,aarch64-apple-,x86_64-mingw-1,i686-msvc-

@rust-bors

rust-bors Bot commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

📌 Commit 378ce78 has been approved by JonathanBrouwer

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 6, 2026
@rust-bors

rust-bors Bot commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

⌛ Trying commit 378ce78 with merge f5bea76

To cancel the try build, run the command @bors try cancel.

Workflow: https://github.com/rust-lang/rust/actions/runs/31082375344

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


try-job: dist-various-1
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
try-job: i686-msvc-*
@JonathanBrouwer

Copy link
Copy Markdown
Contributor Author

@bors try cancel

@rust-bors

rust-bors Bot commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

Try build cancelled. Cancelled workflows:

@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 6, 2026
@rust-bors

rust-bors Bot commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

This pull request was unapproved due to being closed.

@rust-bors rust-bors Bot removed the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Aug 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-attributes Area: Attributes (`#[…]`, `#![…]`) A-CI Area: Our Github Actions CI A-testsuite Area: The testsuite used to check the correctness of rustc 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-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-infra Relevant to the infrastructure 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. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver)

Projects

None yet

Development

Successfully merging this pull request may close these issues.