Rollup of 2 pull requests by JonathanBrouwer · Pull Request #156794 · rust-lang/rust

JonathanBrouwer · 2026-05-21T10:21:47Z

Successful merges:

Remove unsound target_feature_inline_always feature #156242 (Remove unsound target_feature_inline_always feature)
Unsafe kept in help text #156791 (Unsafe kept in help text)

r? @ghost

Create a similar rollup

…pport, reinstating error message and providing a link to the tracking issue for the full rationale.

….rs`'s

…`register_removed(...)` call

…inealways + target feature changes, factoring in subsequent codebase changes

@RalfJung

…ine+target-feature, r=RalfJung,saethlin Remove unsound `target_feature_inline_always` feature ## Summary - Remove `target_feature_inline_always` - Update stdarch generators to only use `#[inline]` & regenerate stdarch. ## Why? Succinctly; the feature relies on LLVMs `AlwaysInlinerPass()` running before LLVMs heuristic based inliner pass. Which is not a basis for sound code. This has been discussed in [the tracking issue](rust-lang#145574). If the ordering of the passes were to change, of which they have in the past, it is very possible we could inline functions across callsites with mismatching target features leading to unsound code. Checks proposed in; rust-lang#155426 would only take into account caller -> callee which is not enough to guard against possibly of generating unsound code if the pass ordering were to change. There doesn't seem to be a way, presently, this this mechanism to provide soundness guarantees nor does it seem like `AlwaysInlinerPass()` is a desired feature of LLVM, which this feature relies on. r? @RalfJung

@jdonszelmann

…t, r=JonathanBrouwer,Kivooeo Unsafe kept in help text Currently when encountering a malformed attribute, the compiler will suggest removing unsafe in the well-formed template even when unsafe is required. This PR preserves whatever unsafe (or lack) exists in the user's code. r? @jdonszelmann

JonathanBrouwer · 2026-05-21T10:22:00Z

@bors r+ rollup=never p=5

rust-bors · 2026-05-21T10:22:03Z

📌 Commit f84347a has been approved by JonathanBrouwer

It is now in the queue for this repository.

rust-bors · 2026-05-21T13:31:55Z

☀️ Test successful - CI
Approved by: JonathanBrouwer
Duration: 3h 8m 52s
Pushing 037b621 to main...

rust-timer · 2026-05-21T13:32:35Z

📌 Perf builds for each rolled up PR:

PR#	Message	Perf Build Sha
#156242	Remove unsound `target_feature_inline_always` feature	`f18f4f04be630a78d2144de07d16680605e9a22d` (link)
#156791	Unsafe kept in help text	`c5fccf7bffe7befdfb2af4f9dc033a4b7e643e99` (link)

previous master: b954122bbe

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-05-21T13:35:22Z

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 b954122 (parent) -> 037b621 (this PR)

Test differences

Show 633 test diffs

Stage 1

[codegen] tests/codegen-llvm/inline-always-callsite.rs: pass -> [missing] (J3)
[ui] tests/ui/feature-gates/feature-gate-target-feature-inline-always.rs: ignore (only executed when the architecture is aarch64) -> [missing] (J4)
[ui] tests/ui/target-feature/inline-always.rs#aarch64: pass -> [missing] (J4)

Stage 2

[codegen] tests/codegen-llvm/inline-always-callsite.rs: pass -> [missing] (J0)
[ui] tests/ui/target-feature/inline-always.rs#aarch64: ignore (gcc backend is marked as ignore) -> [missing] (J1)
[ui] tests/ui/target-feature/inline-always.rs#aarch64: pass -> [missing] (J2)
[ui] tests/ui/feature-gates/feature-gate-target-feature-inline-always.rs: pass -> [missing] (J5)
[ui] tests/ui/feature-gates/feature-gate-target-feature-inline-always.rs: ignore (only executed when the architecture is aarch64) -> [missing] (J6)

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

Job group index

J0: aarch64-apple, aarch64-gnu, aarch64-gnu-llvm-21-1, aarch64-msvc-1, arm-android, armhf-gnu, dist-i586-gnu-i586-i686-musl, i686-gnu-1, i686-gnu-nopt-1, i686-msvc-1, optional-x86_64-gnu-parallel-frontend, test-various, x86_64-gnu, x86_64-gnu-llvm-21-2, x86_64-gnu-llvm-22-2, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-1, x86_64-msvc-1
J1: x86_64-gnu-gcc
J2: aarch64-apple, aarch64-gnu, aarch64-gnu-llvm-21-1, aarch64-msvc-1, arm-android, armhf-gnu, dist-i586-gnu-i586-i686-musl, i686-gnu-1, i686-gnu-nopt-1, i686-msvc-1, optional-x86_64-gnu-parallel-frontend, test-various, x86_64-gnu, x86_64-gnu-debug, x86_64-gnu-llvm-21, x86_64-gnu-llvm-21-2, x86_64-gnu-llvm-22-2, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-1, x86_64-msvc-1
J3: pr-check-2, x86_64-gnu-llvm-21-3, x86_64-gnu-llvm-22-3
J4: x86_64-gnu-llvm-21-3, x86_64-gnu-llvm-22-3
J5: aarch64-apple, aarch64-gnu, aarch64-gnu-llvm-21-1, aarch64-msvc-1
J6: arm-android, armhf-gnu, dist-i586-gnu-i586-i686-musl, i686-gnu-1, i686-gnu-nopt-1, i686-msvc-1, optional-x86_64-gnu-parallel-frontend, test-various, x86_64-gnu, x86_64-gnu-debug, x86_64-gnu-gcc, x86_64-gnu-llvm-21, x86_64-gnu-llvm-21-2, x86_64-gnu-llvm-22-2, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-1, x86_64-msvc-1

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 037b621e831cba9ebd4148f9de33eff361df23d3 --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

x86_64-gnu-gcc: 51m 56s -> 1h 9m (+32.9%)
x86_64-msvc-ext2: 1h 53m -> 1h 26m (-23.8%)
dist-arm-linux-gnueabi: 1h 12m -> 1h 28m (+22.3%)
dist-loongarch64-musl: 1h 51m -> 1h 27m (-21.8%)
x86_64-mingw-1: 2h 19m -> 2h 49m (+21.8%)
dist-armv7-linux: 1h 14m -> 1h 30m (+20.8%)
pr-check-2: 39m 17s -> 46m 32s (+18.5%)
dist-ohos-x86_64: 1h 17m -> 1h 4m (-16.5%)
dist-apple-various: 1h 44m -> 2h (+15.8%)
i686-gnu-2: 1h 28m -> 1h 41m (+15.7%)

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-05-21T14:14:35Z

Finished benchmarking commit (037b621): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

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.3%	[0.2%, 0.4%]	64
Regressions ❌ (secondary)	0.3%	[0.1%, 0.4%]	38
Improvements ✅ (primary)	-0.3%	[-0.5%, -0.2%]	9
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.2%]	8
All ❌✅ (primary)	0.2%	[-0.5%, 0.4%]	73

Max RSS (memory usage)

Results (primary 2.1%, secondary 3.2%)

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

	mean	range	count
Regressions ❌ (primary)	2.1%	[2.1%, 2.1%]	1
Regressions ❌ (secondary)	3.2%	[0.6%, 5.7%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.1%	[2.1%, 2.1%]	1

Cycles

Results (primary -2.1%, secondary -0.8%)

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

Binary size

Results (primary -0.1%, secondary -0.1%)

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.1%	[-0.1%, -0.0%]	78
Improvements ✅ (secondary)	-0.1%	[-0.2%, -0.0%]	29
All ❌✅ (primary)	-0.1%	[-0.1%, -0.0%]	78

Bootstrap: 514.377s -> 511.013s (-0.65%)
Artifact size: 400.61 MiB -> 400.50 MiB (-0.03%)

JonathanBrouwer · 2026-05-21T18:12:45Z

Caused by #156242

Jamesbarford and others added 11 commits May 7, 2026 08:28

Remove #[inline(always)] + #[target_feature(enable = "<feature>")] su…

c6d2da9

…pport, reinstating error message and providing a link to the tracking issue for the full rationale.

Remove target_feature_inline_always from core, std and stdarch `lib…

52cc7ec

….rs`'s

Update tests to reflect changes, deleted ones that are now irrelevant

311cda6

PR Feedback - grammatical changes, clear reason for removal and move …

812e230

…`register_removed(...)` call

Fix for new error message

0453288

PR feedback - revert fn inline_attr(...) to how it was prior to inl…

405214d

…inealways + target feature changes, factoring in subsequent codebase changes

Make attr template suggestions preserve attribute safety.

835004a

Make attr template suggestions preserve attribute safety.

9c9f439

Use ast node instead of boolean

970cb15

rust-bors Bot added the rollup A PR which is a rollup label May 21, 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 May 21, 2026

rust-bors Bot mentioned this pull request May 21, 2026

Remove unsound target_feature_inline_always feature #156242

Merged

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 May 21, 2026

rust-bors Bot merged commit 037b621 into rust-lang:main May 21, 2026
12 checks passed

rustbot added this to the 1.97.0 milestone May 21, 2026

This was referenced May 21, 2026

treat no_mangle_generic_items as hard error instead of lint warning #154585

Open

make repr_transparent_non_zst_fields a hard error #155299

Open

rustbot added the perf-regression Performance regression. label May 21, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Rollup of 2 pull requests#156794

Rollup of 2 pull requests#156794
rust-bors[bot] merged 11 commits into
rust-lang:mainfrom
JonathanBrouwer:rollup-VOF2Ff4

JonathanBrouwer commented May 21, 2026

Uh oh!

JonathanBrouwer commented May 21, 2026

Uh oh!

rust-bors Bot commented May 21, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented May 21, 2026

Uh oh!

Uh oh!

rust-timer commented May 21, 2026

Uh oh!

github-actions Bot commented May 21, 2026

Stage 1

Stage 2

Uh oh!

rust-timer commented May 21, 2026

Uh oh!

JonathanBrouwer commented May 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Uh oh!

Conversation

JonathanBrouwer commented May 21, 2026

Uh oh!

JonathanBrouwer commented May 21, 2026

Uh oh!

rust-bors Bot commented May 21, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented May 21, 2026

Uh oh!

Uh oh!

rust-timer commented May 21, 2026

Uh oh!

github-actions Bot commented May 21, 2026

Test differences

Stage 1

Stage 2

Job duration changes

Uh oh!

rust-timer commented May 21, 2026

Overall result: ❌✅ regressions and improvements - please read:

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

JonathanBrouwer commented May 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants