Rollup of 5 pull requests by matthiaskrgr · Pull Request #154802 · rust-lang/rust

matthiaskrgr · 2026-04-04T09:09:26Z

Successful merges:

Remove more BuiltinLintDiag variants - part 4 #154376 (Remove more BuiltinLintDiag variants - part 4)
llvm: Fix array ABI test to not check equality implementation #154731 (llvm: Fix array ABI test to not check equality implementation)
feat(core): impl Step for NonZero<u*> #127534 (feat(core): impl Step for NonZero<u*>)
Fix trailing comma in lifetime suggestion for empty angle brackets #154703 (Fix trailing comma in lifetime suggestion for empty angle brackets)
Fix ICE in read_discriminant for enums with non-contiguous discriminants #154776 (Fix ICE in read_discriminant for enums with non-contiguous discriminants)

Implement Step for NonZero unsigned integers as discussed in [libs-team#130][1]. [1]: rust-lang/libs-team#130 `step_nonzero_impls` was adapted from `step_integer_impls` and the tests were adapted from the step tests. Signed-off-by: Jalil David Salamé Messina <jalil.salame@gmail.com>

…o downcast to `Session`

LLVM has moved memcmp expansion in the pipeline, resulting in the bcmp call being expanded into loads and register comparisons, which breaks the test. Based on history, I believe the test actually intended validate that these arrays were being passed as pointer arguments, which can be done more directly.

@JonathanBrouwer

…athanBrouwer Remove more BuiltinLintDiag variants - part 4 Part of rust-lang#153099. I wonder if there will be any impact on perf by doing this code all the time. Gonna check. r? @JonathanBrouwer

@durin42

llvm: Fix array ABI test to not check equality implementation LLVM has moved memcmp expansion in the pipeline, resulting in the bcmp call being expanded into loads and register comparisons, which breaks the test. See llvm/llvm-project#77370 Based on history, I believe the test actually intended validate that these arrays were being passed as pointer arguments, which can be done more directly. r? @durin42 cc @scottmcm (author of the test being modified) @rustbot label llvm-main

…programmerjake,tgross35 feat(core): impl Step for NonZero<u*> Implement Step for NonZero unsigned integers as discussed in [libs-team#130][1]. [1]: rust-lang/libs-team#130 `step_nonzero_impls` was adapted from `step_integer_impls` and the tests were adapted from the step tests. It seems to compile and pass the tests c: I would like to test the edge cases, specially around overflows. To ensure safe code cannot generate a 0 `NonZero`, but I don't know how to go about it. I would love some feedback on that (and the PR overall). The impls are tagges with `#[unstable(feature = "step_trait", reason = "recently redesigned", issue = "42168")]`. I assumed this was appropriate, but I am not sure.

…ma, r=chenyukang Fix trailing comma in lifetime suggestion for empty angle brackets Fixes rust-lang#154600 When suggesting a lifetime parameter (e.g., `'a`) for a type like `Foo<>` (empty angle brackets), the compiler was incorrectly producing `Foo<'a, >` with a trailing comma. ## Root Cause The `has_existing_params` check used `segment.args` to determine if generic parameters exist. However, for empty angle brackets (`<>`), the parser doesn't create any `args`, so `has_existing_params` was `false` — even though the angle brackets themselves exist. This caused the suggestion logic to skip the comma+space suffix (`"'a, "`), but the insert position was still inside the angle brackets, leading to `Foo<'a, >` instead of `Foo<'a>`. ## Fix Replace the `segment.args`-based check with a source text inspection using `span_to_snippet`. The new logic: 1. Finds the `<` character in the source text 2. Extracts the content between `<` and `>` 3. Checks if that content is non-empty (after trimming whitespace) This correctly identifies `<>` as having no existing parameters, avoiding the trailing comma. ## Test Added `tests/ui/lifetimes/E0106-trailing-comma-in-lifetime-suggestion.rs` covering the specific case of empty angle brackets with lifetime suggestions.

…e, r=RalfJung Fix ICE in read_discriminant for enums with non-contiguous discriminants so, investigation of rust-lang#153758 took a while. it seems, that reverting back to older approach is the best we can do there. > `read_discriminant `ICEs (unwrap on `None`) when an enum's `valid_range` is wider than its set of actual discriminants. this happens for enums with gaps in their discriminant values — e.g. `{0, 2, 3, 4, 5} `has `` valid_range`` 0..=5 `` which includes `1`, or `{i64::MIN, i64::MAX}` has a wrapping range covering everything. [b840338](rust-lang@b840338) commit added a `valid_range` check and replaced the prior `.ok_or_else(|| err_ub!(InvalidTag(...)))` with `.unwrap()`, assuming the range check would guarantee a matching variant. that assumption is wrong for non-contiguous discriminants. my fix restores the fallible lookup, returning `InvalidTag` UB instead of panicking. also it affected crates - **sec1, ntex-mqtt**, when compiled with optimizations, where the `jump_threading` MIR pass constructs constants with tag values inside the `valid_range` but not matching any actual variant.

matthiaskrgr · 2026-04-04T09:09:43Z

@bors r+ rollup=never p=5

rust-bors · 2026-04-04T09:09:46Z

📌 Commit 7f18b25 has been approved by matthiaskrgr

It is now in the queue for this repository.

matthiaskrgr · 2026-04-04T09:11:26Z

@bors try jobs=aarch64-msvc-1

Rollup of 5 pull requests try-job: aarch64-msvc-1

rust-bors · 2026-04-04T11:21:10Z

☀️ Try build successful (CI)
Build commit: c2bfb85 (c2bfb8594f5211f5bb240683516976b1fb179f02, parent: 2972b5e59f1c5529b6ba770437812fd83ab4ebd4)

rust-bors · 2026-04-04T17:45:35Z

☀️ Test successful - CI
Approved by: matthiaskrgr
Duration: 3h 8m 32s
Pushing 0312a55 to main...

rust-timer · 2026-04-04T17:47:06Z

📌 Perf builds for each rolled up PR:

PR#	Message	Perf Build Sha
#127534	feat(core): impl Step for NonZero<u*>	`5a39fdd8dfea9811eff7321f1bd84f29dc926302` (link)
#154376	Remove more BuiltinLintDiag variants - part 4	`1c35a614432d06b16bed56e24867d066c7cf658e` (link)
#154703	Fix trailing comma in lifetime suggestion for empty angle b…	`c25bd84c5695fa4ce38b655e0788bcc2c23272a0` (link)
#154731	llvm: Fix array ABI test to not check equality implementati…	`dfb66f34ecb74383e1750ba591b6486aadba670f` (link)
#154776	Fix ICE in read_discriminant for enums with non-contiguous …	`60015eacfcaf9a7831e87d56ed8a55972d8e7bd9` (link)

previous master: 981cf69479

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 · 2026-04-04T17:48:25Z

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 981cf69 (parent) -> 0312a55 (this PR)

Test differences

Show 55 test diffs

Stage 1

[codegen] tests/codegen-llvm/array-equality.rs: ignore (only executed when the architecture is x86_64) -> [missing] (J2)
[codegen] tests/codegen-llvm/array-equality.rs#llvm-current: [missing] -> ignore (only executed when the architecture is x86_64) (J2)
[codegen] tests/codegen-llvm/array-equality.rs#llvm-next: [missing] -> ignore (only executed when the architecture is x86_64) (J2)
[codegen] tests/codegen-llvm/array-equality.rs: pass -> [missing] (J5)
[codegen] tests/codegen-llvm/array-equality.rs#llvm-current: [missing] -> pass (J5)
[ui] tests/ui/lifetimes/E0106-trailing-comma-in-lifetime-suggestion.rs: [missing] -> pass (J5)
[codegen] tests/codegen-llvm/array-equality.rs#llvm-next: [missing] -> ignore (ignored when the LLVM version 21.1.2 is older than 23.0.0) (J7)
[codegen] tests/codegen-llvm/array-equality.rs#llvm-next: [missing] -> ignore (ignored when the LLVM version 22.1.1 is older than 23.0.0) (J8)
iter::range::test_nonzero_range: [missing] -> pass (J9)

Stage 2

[codegen] tests/codegen-llvm/array-equality.rs#llvm-next: [missing] -> ignore (ignored when the LLVM version 22.1.1 is older than 23.0.0) (J0)
[codegen] tests/codegen-llvm/array-equality.rs#llvm-next: [missing] -> ignore (ignored when the LLVM version 22.1.2 is older than 23.0.0) (J1)
[codegen] tests/codegen-llvm/array-equality.rs: pass -> [missing] (J3)
[codegen] tests/codegen-llvm/array-equality.rs#llvm-current: [missing] -> pass (J3)
[ui] tests/ui/lifetimes/E0106-trailing-comma-in-lifetime-suggestion.rs: [missing] -> pass (J4)
[codegen] tests/codegen-llvm/array-equality.rs: ignore (only executed when the architecture is x86_64) -> [missing] (J6)
[codegen] tests/codegen-llvm/array-equality.rs#llvm-current: [missing] -> ignore (only executed when the architecture is x86_64) (J6)
[codegen] tests/codegen-llvm/array-equality.rs#llvm-next: [missing] -> ignore (only executed when the architecture is x86_64) (J6)
iter::range::test_nonzero_range: [missing] -> pass (J10)
[codegen] tests/codegen-llvm/array-equality.rs#llvm-next: [missing] -> ignore (ignored when the LLVM version 21.1.2 is older than 23.0.0) (J11)

Additionally, 36 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 0312a55fe4200208170b94bf287ca3cc7ea499ae --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

dist-apple-various: 1h 49m -> 1h 25m (-22.1%)
aarch64-apple: 3h 25m -> 2h 47m (-18.5%)
dist-arm-linux-musl: 1h 36m -> 1h 19m (-18.1%)
pr-check-1: 34m 8s -> 28m 6s (-17.6%)
x86_64-gnu-llvm-21: 1h 17m -> 1h 6m (-14.8%)
i686-gnu-2: 1h 41m -> 1h 26m (-14.4%)
aarch64-gnu-debug: 1h 14m -> 1h 6m (-11.1%)
x86_64-rust-for-linux: 53m 11s -> 47m 20s (-11.0%)
test-various: 2h 7m -> 1h 53m (-10.9%)
dist-aarch64-llvm-mingw: 1h 33m -> 1h 43m (+10.8%)

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 · 2026-04-04T18:26:39Z

Finished benchmarking commit (0312a55): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

If the regression was expected or you think it can be justified,
please write a comment with sufficient written justification, and add
@rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
If you think that you know of a way to resolve the regression, try to create
a new PR with a fix for the regression.
If you do not understand the regression or you think that it is just noise,
you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.2%	[0.0%, 0.4%]	10
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.6%	[-1.6%, -0.0%]	3
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -1.0%, secondary 2.4%)

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

	mean	range	count
Regressions ❌ (primary)	1.2%	[1.2%, 1.2%]	1
Regressions ❌ (secondary)	3.0%	[1.9%, 5.4%]	5
Improvements ✅ (primary)	-2.1%	[-2.3%, -2.0%]	2
Improvements ✅ (secondary)	-0.8%	[-0.8%, -0.8%]	1
All ❌✅ (primary)	-1.0%	[-2.3%, 1.2%]	3

Cycles

Results (primary -0.4%, secondary -4.7%)

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

	mean	range	count
Regressions ❌ (primary)	2.5%	[2.5%, 2.5%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-3.4%	[-3.4%, -3.4%]	1
Improvements ✅ (secondary)	-4.7%	[-5.1%, -4.4%]	5
All ❌✅ (primary)	-0.4%	[-3.4%, 2.5%]	2

Binary size

Results (secondary -0.0%)

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)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.0%	[-0.0%, -0.0%]	1
All ❌✅ (primary)	-	-	0

Bootstrap: 485.459s -> 489.356s (0.80%)
Artifact size: 395.00 MiB -> 395.11 MiB (0.03%)

Mark-Simulacrum · 2026-04-06T12:09:56Z

Regression almost certainly due to #154376 (comment), that perf run matches pretty closely what we see here. I don't think further investigation is warranted, the affected benchmark intentionally stresses the lint system (unused-warnings).

fru1tworld and others added 13 commits April 3, 2026 11:28

Increase span_look_ahead limit to handle whitespace

46b0527

Remove BuiltinLintDiag::SingleUseLifetime

1337370

Remove BuiltinLintDiag::AbsPathWithModule

99f9ba0

Make DecorateDiagCompat::Dynamic take an Any reference allowing t…

6f751ec

…o downcast to `Session`

Fix ICE in read_discriminant for enums with non-contiguous discriminants

a082578

Fix merge conflict

df848e7

Rollup merge of rust-lang#154376 - GuillaumeGomez:migrate-diag, r=Jon…

643f45e

…athanBrouwer Remove more BuiltinLintDiag variants - part 4 Part of rust-lang#153099. I wonder if there will be any impact on perf by doing this code all the time. Gonna check. r? @JonathanBrouwer

rust-bors bot added the rollup A PR which is a rollup label Apr 4, 2026

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. labels Apr 4, 2026

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 4, 2026

This comment has been minimized.

Sign in to view

rust-bors bot pushed a commit that referenced this pull request Apr 4, 2026

Auto merge of #154802 - matthiaskrgr:rollup-HWNmEyC, r=<try>

c2bfb85

Rollup of 5 pull requests try-job: aarch64-msvc-1

This comment has been minimized.

Sign in to view

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 4, 2026

rust-bors bot merged commit 0312a55 into rust-lang:main Apr 4, 2026
13 checks passed

rustbot added this to the 1.96.0 milestone Apr 4, 2026

rustbot added the perf-regression Performance regression. label Apr 4, 2026

Mark-Simulacrum mentioned this pull request Apr 6, 2026

Remove more BuiltinLintDiag variants - part 4 #154376

Merged

Mark-Simulacrum added the perf-regression-triaged The performance regression has been triaged. label Apr 6, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Rollup of 5 pull requests#154802

Rollup of 5 pull requests#154802
rust-bors[bot] merged 13 commits intorust-lang:mainfrom
matthiaskrgr:rollup-HWNmEyC

matthiaskrgr commented Apr 4, 2026

Uh oh!

matthiaskrgr commented Apr 4, 2026

Uh oh!

rust-bors bot commented Apr 4, 2026

Uh oh!

matthiaskrgr commented Apr 4, 2026

Uh oh!

This comment has been minimized.

rust-bors bot commented Apr 4, 2026

Uh oh!

This comment has been minimized.

rust-bors bot commented Apr 4, 2026

Uh oh!

Uh oh!

rust-timer commented Apr 4, 2026

Uh oh!

github-actions bot commented Apr 4, 2026

Stage 1

Stage 2

Uh oh!

rust-timer commented Apr 4, 2026

Uh oh!

Mark-Simulacrum commented Apr 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

Uh oh!

Conversation

matthiaskrgr commented Apr 4, 2026

Uh oh!

matthiaskrgr commented Apr 4, 2026

Uh oh!

rust-bors bot commented Apr 4, 2026

Uh oh!

matthiaskrgr commented Apr 4, 2026

Uh oh!

This comment has been minimized.

rust-bors bot commented Apr 4, 2026

Uh oh!

This comment has been minimized.

rust-bors bot commented Apr 4, 2026

Uh oh!

Uh oh!

rust-timer commented Apr 4, 2026

Uh oh!

github-actions bot commented Apr 4, 2026

Test differences

Stage 1

Stage 2

Job duration changes

Uh oh!

rust-timer commented Apr 4, 2026

Overall result: ❌✅ regressions and improvements - please read the text below

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

Mark-Simulacrum commented Apr 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants