Skip to content

Rollup of 8 pull requests#155099

Merged
rust-bors[bot] merged 29 commits intorust-lang:mainfrom
JonathanBrouwer:rollup-nKbnTlV
Apr 10, 2026
Merged

Rollup of 8 pull requests#155099
rust-bors[bot] merged 29 commits intorust-lang:mainfrom
JonathanBrouwer:rollup-nKbnTlV

Conversation

@JonathanBrouwer
Copy link
Copy Markdown
Contributor

Successful merges:

r? @ghost

Create a similar rollup

GokhanKabar and others added 29 commits March 13, 2026 00:16
Builtin attribute macros like #[eii] generate AST items
programmatically without collected tokens. When another attribute macro
was present on the same item, the compiler would panic in
TokenStream::from_ast() trying to tokenize the generated items during
subsequent attribute expansion.

Generate fake token streams (via pretty-print and re-parse) for Item
and ForeignItem nodes that lack collected tokens, following the
existing pattern used for Crate and out-of-line modules.
Add bit-or detection in lower expr within pattern.

Previously `pat1 | pat2` in `$e:expr` failed to trigger
`.pattern_from_macro_note` diagnostic bc
`ast::Expr::is_approximately_pattern()` did not cover bit-or.
…ass test

When a function has `eii_impls` set (via `eii_shared_macro`), the `#[hello]`
attribute is consumed from `node.attrs()`. A subsequent `AttrProcMacro` expander
like `contracts::requires` calls `item.to_tokens()` which uses the current
`node.attrs()` — so `#[hello]` is missing from the token stream. After the
roundtrip and `parse_ast_fragment`, the new AST item has empty `eii_impls`
and the EII link is broken.

Fix this by using `fake_token_stream_for_item` when the item is a function
with non-empty `eii_impls`. The pretty-printer re-emits `eii_impls` as
`#[hello]` in `print_fn_full`, which survives the roundtrip and gets
re-expanded by `eii_shared_macro` on the resulting item.

Add a run-pass test to verify EII + contract annotation works correctly
at runtime.
…erated_item test

The previous test used `fn implementation() {}` with a body, which caused
`generate_default_impl` to generate a `const _: () = { fn implementation() {} }`
item containing `self::implementation`. On Linux (aarch64-gnu-llvm-21), the
resolver's `suggest_ident_hidden_by_hygiene` emitted an extra help span on the
resulting E0425 error that did not appear on macOS, causing a stderr mismatch.

Switch the declaration to `fn implementation();` (no body) so that
`generate_default_impl` is not called and no `self::implementation` path is
emitted. The test still validates that `#[eii]` + `#[core::contracts::ensures]`
produces graceful errors instead of an ICE, via the two contract-annotation
errors on the generated foreign item.
It doesn't need to be in there, it can instead be at the single call
site. Removing it eliminates one parameter, makes `define_queries!`
smaller (which is always good), and also enables the next commit which
tidies up profiling.

This commit also changes how `value` and `verify` are initialized,
because I don't like the current way of doing it after the declaration.
From `plumbing.rs` to `execution.rs`, which is where most of the other
query profiling occurs. It also avoids eliminates some fn parameters.

This means the `provided_to_erased` call in `try_from_load_disk_fn` is
now included in the profiling when previously it wasn't. This is
good because `provided_to_erased` is included in other profiling calls
(e.g. calls to `invoke_provider_fn`).
Moreover, dereference `ty_layout.align` for `#[rustc_dump_layout(align)]`
to render `align: Align($N bytes)` instead of `align: AbiAlign { abi: Align($N bytes) }`
which contains the same amount of information but it more concise and legible.
…g-mode, r=lcnr

Always exhaustively match on typing mode

r? @lcnr

Unimplements Eq/PartialEq for TypingMode, adds TypingModeEqWrapper for the few cases where we need it (mainly in the query system), and adds a new rustc internal lint to detect cases where we non-exhaustively match on typing mode.
Simplify `try_load_from_disk_fn`.

`try_load_from_disk_fn` has a single call site. We can move some of the stuff within it to its single call site, which simplifies it, and also results in all of the query profiling code ending up in the same module. Details in individual commits.

r? @Zalathar
…clean, r=jdonszelmann

Restrict EII declarations to functions at lowering time

We tighten EII declaration resolution so that `lower_path_simple_eii` only accepts function‑like items (`Fn, AssocFn, Ctor(_, Fn)`) as valid EII targets. If name resolution points at something else (like a const with the same name), we now emit a direct error (“`externally implementable items must refer to a function`”) at the declaration site, which prevents bad `DefIds` from ever reaching `compare_eii_function_types` and turning into an ICE

this is more robust and root-cause oriented fix to rust-lang#152337 issue and an alternate of my more simple PR rust-lang#152365

test included
…-eii-attr-expansion, r=jdonszelmann

Fix ICE when combining #[eii] with #[core::contracts::ensures]

Fixes rust-lang#153745

Builtin attribute macros like #[eii] generate AST items programmatically without collected tokens. When another attribute macro was present on the same item, the compiler would panic in TokenStream::from_ast() trying to tokenize the generated items during subsequent attribute expansion.

Generate fake token streams (via pretty-print and re-parse) for Item and ForeignItem nodes that lack collected tokens, following the existing pattern used for Crate and out-of-line modules.
… r=JohnTitor

Fix `pattern_from_macro_note` for bit-or expr

This is a continuation of issue rust-lang#99380 (and pr rust-lang#124488) but covers bit-or pattern.

Essentially a `pat1 | pat2`, or any bit-or pattern used in a `$e:expr` was not firing the `.pattern_from_macro_note` diagnostic bc `ast::Expr::is_approximately_pattern()` did not cover bit-or.

The cover for bit-or is only added in `lower_expr_within_pat()`, otherwise doing it in `is_approximately_pattern()` would result in the suggestion `if (i + 2) = 2 => if let (i + 2) = 2` from `suggest_pattern_match_with_let()` (which is the only other place `ast::Expr::is_approximately_pattern()` is used from what i see).

resolves rust-lang#99380
refs rust-lang#124488
…=JonathanBrouwer

 Rename some more of our internal `#[rustc_*]` TEST attributes

Follow-up to rust-lang#153300.

r? JonathanBrouwer or jdonszelmann
…lowering-ice, r=petrochenkov

delegation: fix unelided lifetime ICE, refactoring of GenericArgPosition

This PR does two things:
- First it restores `lower_generic_args_of_path` as it was before rust-lang#151864, as it turns out we should use `GenericArgPosition::Type` for generic args lowering for signature inheritance, as it will not cause lifetime inference and then ICEs during child args lowering,
- Next it refactors `GenericArgPosition` enum replacing `Value` and `MethodCall` with `Call(IsMethodCall)`, as the only place where we created `Value` or `MethodCall` variants was in `check_generic_arg_count_for_call`, where it was a match over `is_method_call`. Not sure it is needed, but seems cleaner to me.

Fixes rust-lang#154178, part of rust-lang#118212.

r? @petrochenkov
… r=JohnTitor

Fix code block whitespace handling in Markdown

### Fix Markdown code block closing whitespace handling

Previously, the parser incorrectly accepted closing backticks followed by extra text and rejected lines where only spaces appeared after closing backticks. This did not match expected Markdown behavior.

Now, the parser correctly ends a code block only when line after the code ends with spaces or nothing. Lines where extra text appears after the closing backticks are treated as part of the code block.

Includes tests for both correct and incorrect cases.

### Related issue

This PR addresses the Outreachy issue: [Markdown whitespace bug in Rust Compiler](rustfoundation/interop-initiative#53)
@rust-bors rust-bors bot added the rollup A PR which is a rollup label Apr 10, 2026
@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) A-rustc-dev-guide Area: rustc-dev-guide S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-clippy Relevant to the Clippy team. T-compiler Relevant to the compiler 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. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) labels Apr 10, 2026
@JonathanBrouwer
Copy link
Copy Markdown
Contributor Author

@bors r+ rollup=never p=5

@rust-bors
Copy link
Copy Markdown
Contributor

rust-bors bot commented Apr 10, 2026

📌 Commit eec05ee 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 Apr 10, 2026
@rust-bors

This comment has been minimized.

@rust-bors rust-bors bot added merged-by-bors This PR was explicitly merged by bors. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Apr 10, 2026
@rust-bors
Copy link
Copy Markdown
Contributor

rust-bors bot commented Apr 10, 2026

☀️ Test successful - CI
Approved by: JonathanBrouwer
Duration: 3h 34m 38s
Pushing b6100cc to main...

@rust-bors rust-bors bot merged commit b6100cc into rust-lang:main Apr 10, 2026
12 checks passed
@rustbot rustbot added this to the 1.96.0 milestone Apr 10, 2026
@rust-timer
Copy link
Copy Markdown
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#152384 Restrict EII declarations to functions at lowering time eb851eaf6a4566a8e9662f6bfc72873342eec781 (link)
#153796 Fix ICE when combining #[eii] with #[core::contracts::ensur… 6a91907f0cd7a56a76f97312ec9c8b9e6b720c98 (link)
#154369 Fix pattern_from_macro_note for bit-or expr 12c7a3ff4ca3840d73336fdbb0fd09b36abbd4c7 (link)
#155027 Rename some more of our internal #[rustc_*] TEST attribu… 3d898ccf34be78188fad449bf3d02f6f1d78b42c (link)
#155031 delegation: fix unelided lifetime ICE, refactoring of Gener… de70c26893366ab66172a3ccd67f72b83ccc4c20 (link)
#155040 Fix code block whitespace handling in Markdown 88b4896638f022df1c4d1da30f7ae839236e3509 (link)
#155047 Always exhaustively match on typing mode 37f6ccc3dc0a670a21d9cb8aae76801126908138 (link)
#155080 Simplify try_load_from_disk_fn. db1234607e24370575a7a468291fb020a894006c (link)

previous master: 8317fef204

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

@github-actions
Copy link
Copy Markdown
Contributor

What is this? This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 8317fef (parent) -> b6100cc (this PR)

Test differences

Show 72 test diffs

Stage 0

  • markdown::parse::tests::test_codeblock_trailing_whitespace: [missing] -> pass (J4)

Stage 1

  • markdown::parse::tests::test_codeblock_trailing_whitespace: [missing] -> pass (J3)
  • [ui] tests/ui-fulldeps/internal-lints/must_match_exhaustively.rs: [missing] -> ignore (ignored when the bootstrapping stage is stage1) (J4)
  • [ui] tests/ui/delegation/generics/unelided-lifetime-ice-154178.rs: [missing] -> pass (J4)
  • [ui] tests/ui/eii/eii-declaration-not-fn-issue-152337.rs: [missing] -> pass (J4)
  • [ui] tests/ui/eii/eii_impl_with_contract.rs: [missing] -> pass (J4)
  • [ui] tests/ui/eii/ice_contract_attr_on_eii_generated_item.rs: [missing] -> pass (J4)

Stage 2

  • [ui] tests/ui/eii/eii_impl_with_contract.rs: [missing] -> ignore (ignored when the operating system is windows) (J0)
  • [ui] tests/ui/eii/eii_impl_with_contract.rs: [missing] -> ignore (gcc backend is marked as ignore) (J1)
  • [ui] tests/ui/eii/eii_impl_with_contract.rs: [missing] -> pass (J2)
  • [ui] tests/ui/delegation/generics/unelided-lifetime-ice-154178.rs: [missing] -> pass (J5)
  • [ui] tests/ui/eii/eii-declaration-not-fn-issue-152337.rs: [missing] -> pass (J5)
  • [ui] tests/ui/eii/ice_contract_attr_on_eii_generated_item.rs: [missing] -> pass (J5)
  • [ui] tests/ui-fulldeps/internal-lints/must_match_exhaustively.rs: [missing] -> pass (J6)

Additionally, 58 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard b6100ccf71c092dd01e7a68930360892545ee4fb --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. aarch64-apple: 2h 44m -> 3h 27m (+26.0%)
  2. dist-i686-mingw: 2h 3m -> 2h 34m (+24.9%)
  3. pr-check-1: 27m 23s -> 33m 35s (+22.6%)
  4. optional-x86_64-gnu-parallel-frontend: 2h 15m -> 2h 44m (+21.8%)
  5. i686-gnu-1: 1h 58m -> 2h 24m (+21.7%)
  6. pr-check-2: 38m 17s -> 45m 30s (+18.9%)
  7. x86_64-gnu-tools: 53m 55s -> 1h 3m (+17.5%)
  8. i686-gnu-2: 1h 31m -> 1h 44m (+14.7%)
  9. x86_64-gnu-llvm-22-1: 1h 6m -> 1h 15m (+13.4%)
  10. i686-gnu-nopt-1: 2h 8m -> 2h 25m (+13.0%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@rust-timer
Copy link
Copy Markdown
Collaborator

Finished benchmarking commit (b6100cc): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This perf run didn't have relevant results for this metric.

Max RSS (memory usage)

Results (primary 1.7%, secondary 2.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
1.8% [0.5%, 4.6%] 26
Regressions ❌
(secondary)
2.2% [0.6%, 4.5%] 29
Improvements ✅
(primary)
-2.4% [-2.4%, -2.4%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 1.7% [-2.4%, 4.6%] 27

Cycles

Results (secondary 5.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
5.4% [2.8%, 8.6%] 6
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 489.232s -> 491.232s (0.41%)
Artifact size: 395.57 MiB -> 394.07 MiB (-0.38%)

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

Labels

A-attributes Area: Attributes (`#[…]`, `#![…]`) A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) A-rustc-dev-guide Area: rustc-dev-guide merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup T-clippy Relevant to the Clippy team. T-compiler Relevant to the compiler 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. 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.