Extending `#[rustc_force_inline]` to be applicable to inherent methods #147231

CrooseGit · 2025-10-01T15:14:54Z

#[rustc_force_inline] is an internal-only attribute similar to #[inline(always)] but which emits an error if inlining cannot occur. rustc_force_inline uses the MIR inliner to do this and has limitations on where it can be applied to ensure that an error is always emitted if inlining can't happen (e.g. it can't be applied to trait methods because calls to those can't always be resolved).

#[rustc_force_inline] is motivated by AArch64 pointer authentication intrinsics where it is vital for the security properties of these intrinsics that they do not exist in standalone functions that could be used as gadgets in an exploit (if they could, then you could sign whatever pointers you want, for example, which is bad, but if you force inlining, then you can't jump to a reusable function containing only these instructions).

Since its initial implementation, #[rustc_force_inline] could only be applied to free functions. This can be relaxed to also allow inherent methods while still preserving the desired properties. In a work-in-progress patch for manual pointer authentication intrinsics, it is useful to introduce types with inherent methods that would need to be force inlined.

r? @saethlin

rustbot · 2025-10-01T15:14:58Z

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann

saethlin · 2025-10-01T23:02:23Z

Thank you for writing a thorough PR description.

@bors r+

bors · 2025-10-01T23:02:27Z

📌 Commit 89bd8f3 has been approved by saethlin

It is now in the queue for this repository.

…c_force_inline, r=saethlin Extending `#[rustc_force_inline]` to be applicable to inherent methods `#[rustc_force_inline]` is an internal-only attribute similar to `#[inline(always)]` but which emits an error if inlining cannot occur. rustc_force_inline uses the MIR inliner to do this and has limitations on where it can be applied to ensure that an error is always emitted if inlining can't happen (e.g. it can't be applied to trait methods because calls to those can't always be resolved). `#[rustc_force_inline]` is motivated by AArch64 pointer authentication intrinsics where it is vital for the security properties of these intrinsics that they do not exist in standalone functions that could be used as gadgets in an exploit (if they could, then you could sign whatever pointers you want, for example, which is bad, but if you force inlining, then you can't jump to a reusable function containing only these instructions). Since its initial implementation, `#[rustc_force_inline]` could only be applied to free functions. This can be relaxed to also allow inherent methods while still preserving the desired properties. In a work-in-progress patch for manual pointer authentication intrinsics, it is useful to introduce types with inherent methods that would need to be force inlined. r? `@saethlin`

Rollup of 10 pull requests Successful merges: - #146281 (Support `#[rustc_align_static]` inside `thread_local!`) - #146535 (mbe: Implement `unsafe` attribute rules) - #146585 (indexing: reword help) - #147004 (Tweak handling of "struct like start" where a struct isn't supported) - #147221 (Forbid `//@ compile-flags: -Cincremental=` in tests) - #147225 (Don't enable shared memory by default with Wasm atomics) - #147227 (implement `Box::take`) - #147231 (Extending `#[rustc_force_inline]` to be applicable to inherent methods) - #147233 (Initialize llvm submodule if not already the case to run citool) - #147236 (Update books) r? `@ghost` `@rustbot` modify labels: rollup

matthiaskrgr · 2025-10-02T06:22:04Z

@bors r-
#147253 (comment)

…c_force_inline, r=saethlin Extending `#[rustc_force_inline]` to be applicable to inherent methods `#[rustc_force_inline]` is an internal-only attribute similar to `#[inline(always)]` but which emits an error if inlining cannot occur. rustc_force_inline uses the MIR inliner to do this and has limitations on where it can be applied to ensure that an error is always emitted if inlining can't happen (e.g. it can't be applied to trait methods because calls to those can't always be resolved). `#[rustc_force_inline]` is motivated by AArch64 pointer authentication intrinsics where it is vital for the security properties of these intrinsics that they do not exist in standalone functions that could be used as gadgets in an exploit (if they could, then you could sign whatever pointers you want, for example, which is bad, but if you force inlining, then you can't jump to a reusable function containing only these instructions). Since its initial implementation, `#[rustc_force_inline]` could only be applied to free functions. This can be relaxed to also allow inherent methods while still preserving the desired properties. In a work-in-progress patch for manual pointer authentication intrinsics, it is useful to introduce types with inherent methods that would need to be force inlined. r? `@saethlin`

matthiaskrgr · 2025-10-02T08:28:54Z

@bors r-

- Changes parser to allow application to inherent methods. - Adds tests to confirm extended functionality works just as the existing.

bors · 2025-10-02T10:32:50Z

@CrooseGit: 🔑 Insufficient privileges: Not in reviewers

CrooseGit · 2025-10-02T10:39:21Z

@saethlin
Some diff files were missing, I have amended the commit and it should be fixed now.

saethlin · 2025-10-02T13:26:34Z

Weird. I thought I had made sure PR CI would fail in that situation.

@bors r+

bors · 2025-10-02T13:26:37Z

📌 Commit 5bf5e71 has been approved by saethlin

It is now in the queue for this repository.

bors · 2025-10-02T21:43:13Z

⌛ Testing commit 5bf5e71 with merge 8d603ef...

bors · 2025-10-03T00:48:14Z

☀️ Test successful - checks-actions
Approved by: saethlin
Pushing 8d603ef to master...

github-actions · 2025-10-03T00:51:26Z

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 5c7ae0c (parent) -> 8d603ef (this PR)

Test differences

Show 16 test diffs

Stage 1

[mir-opt] tests/mir-opt/inline/forced_closure_inherent.rs: [missing] -> pass (J1)
[mir-opt] tests/mir-opt/inline/forced_inherent.rs: [missing] -> pass (J1)
[mir-opt] tests/mir-opt/inline/forced_inherent_ambiguous.rs: [missing] -> pass (J1)
[mir-opt] tests/mir-opt/inline/forced_inherent_async.rs: [missing] -> pass (J1)
[mir-opt] tests/mir-opt/inline/forced_inherent_dead_code.rs: [missing] -> pass (J1)
[ui] tests/ui/force-inlining/inherent.rs: [missing] -> pass (J1)

Stage 2

[mir-opt] tests/mir-opt/inline/forced_closure_inherent.rs: [missing] -> pass (J0)
[mir-opt] tests/mir-opt/inline/forced_inherent.rs: [missing] -> pass (J0)
[mir-opt] tests/mir-opt/inline/forced_inherent_ambiguous.rs: [missing] -> pass (J0)
[mir-opt] tests/mir-opt/inline/forced_inherent_async.rs: [missing] -> pass (J0)
[mir-opt] tests/mir-opt/inline/forced_inherent_dead_code.rs: [missing] -> pass (J0)
[ui] tests/ui/force-inlining/inherent.rs: [missing] -> pass (J2)

Additionally, 4 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 8d603ef2879fd263f8e9aea340b4c035ed7973db --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: 4603.5s -> 3080.5s (-33.1%)
aarch64-apple: 9443.1s -> 7500.9s (-20.6%)
dist-x86_64-freebsd: 6227.8s -> 5023.6s (-19.3%)
dist-i686-msvc: 7921.7s -> 9085.6s (14.7%)
pr-check-1: 1385.2s -> 1571.7s (13.5%)
x86_64-gnu-distcheck: 6188.6s -> 6945.8s (12.2%)
x86_64-gnu-llvm-20-3: 6164.3s -> 6805.3s (10.4%)
dist-aarch64-msvc: 6172.1s -> 5655.7s (-8.4%)
dist-x86_64-mingw: 9296.5s -> 8578.9s (-7.7%)
i686-msvc-2: 7751.9s -> 8346.8s (7.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 · 2025-10-03T02:07:03Z

Finished benchmarking commit (8d603ef): comparison URL.

Overall result: ❌ regressions - 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)	3.1%	[3.1%, 3.1%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	3.1%	[3.1%, 3.1%]	1

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

Results (primary 1.1%)

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

	mean	range	count
Regressions ❌ (primary)	1.1%	[1.1%, 1.1%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.1%	[1.1%, 1.1%]	1

Bootstrap: 471.823s -> 472.119s (0.06%)
Artifact size: 387.78 MiB -> 387.77 MiB (-0.00%)

panstromek · 2025-10-06T15:05:05Z

perf triage:

clap_derive bimodal noise

@rustbot label: +perf-regression-triaged

rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) 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. labels Oct 1, 2025

rustbot assigned saethlin Oct 1, 2025

davidtwco changed the title ~~Extending #[rustc_foce_inline] to be applicable to inherent methods~~ Extending #[rustc_force_inline] to be applicable to inherent methods Oct 1, 2025

bors 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 Oct 1, 2025

Zalathar mentioned this pull request Oct 2, 2025

Rollup of 10 pull requests #147253

Closed

jhpratt mentioned this pull request Oct 2, 2025

Rollup of 10 pull requests #147260

Closed

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 2, 2025

Extends rustc_force_inline to inherent methods

5bf5e71

- Changes parser to allow application to inherent methods. - Adds tests to confirm extended functionality works just as the existing.

CrooseGit force-pushed the dev/reucru01/extend_rustc_force_inline branch from 89bd8f3 to 5bf5e71 Compare October 2, 2025 10:31

bors 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 2, 2025

bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 3, 2025

bors merged commit 8d603ef into rust-lang:master Oct 3, 2025
11 checks passed

rustbot added this to the 1.92.0 milestone Oct 3, 2025

rustbot added the perf-regression Performance regression. label Oct 3, 2025

rustbot added the perf-regression-triaged The performance regression has been triaged. label Oct 6, 2025

Extending #[rustc_force_inline] to be applicable to inherent methods #147231

Extending #[rustc_force_inline] to be applicable to inherent methods #147231

Uh oh!

Conversation

CrooseGit commented Oct 1, 2025

Uh oh!

rustbot commented Oct 1, 2025

Uh oh!

saethlin commented Oct 1, 2025

Uh oh!

bors commented Oct 1, 2025

Uh oh!

matthiaskrgr commented Oct 2, 2025

Uh oh!

matthiaskrgr commented Oct 2, 2025

Uh oh!

bors commented Oct 2, 2025

Uh oh!

CrooseGit commented Oct 2, 2025

Uh oh!

saethlin commented Oct 2, 2025

Uh oh!

bors commented Oct 2, 2025

Uh oh!

bors commented Oct 2, 2025

Uh oh!

bors commented Oct 3, 2025

Uh oh!

Uh oh!

github-actions bot commented Oct 3, 2025

Test differences

Stage 1

Stage 2

Job duration changes

Uh oh!

rust-timer commented Oct 3, 2025

Overall result: ❌ regressions - please read the text below

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

panstromek commented Oct 6, 2025

Uh oh!

Uh oh!

Extending `#[rustc_force_inline]` to be applicable to inherent methods #147231

Extending `#[rustc_force_inline]` to be applicable to inherent methods #147231