Produce an error when `#[inline]` and `#[rust_force_inline]` are used together by tahadostifam · Pull Request #158814 · rust-lang/rust

tahadostifam · 2026-07-05T13:28:20Z

Merged RustcForceInline & Inline Attribute Parsers

I've been reading #153101, #131229 and I came across with this comment in compiler/rustc_attr_parsing/src/attributes/inline.rs:

// FIXME(jdonszelmann): merge these two parsers and error when both attributes are present here.
//                      note: need to model better how duplicate attr errors work when not using
//                      SingleAttributeParser which is what we have two of here.

Having separate SingleAttributeParser implementations for #[rustc_force_inline] and #[inline(...)] meant the compiler wasn't able to recognize cases where both of them were used together on the same item, for example:

#![feature(rustc_attrs)]

#[rustc_force_inline]
#[inline]
fn foo() {}

fn main() {}

This case was previously considered allowed, which is not correct.

My changes replace the distinct attribute parsers with a single unified AttributeParser implementation for InlineParser, handling both attributes together in a single pass. By consolidating the logic, the parser now tracks the state of both attributes side-by-side using an AcceptMapping and introduces a new session diagnostic, InlineForceInlineConflict, which is explicitly triggered in the finalize step if a user attempts to combine them.

An added benefit of catching this conflict early during the parsing phase is that it prevents downstream validation passes (like check_attr) from triggering redundant errors on malformed or incorrectly placed attributes, which naturally cleans up and streamlines our compiler stderr output as reflected in the updated UI test baselines.

This is my very first PR on rustc, and I am incredibly grateful to @hkalbasi, who heavily guided me through the codebase and helped make this change possible!

Sincerely looking for your feedback and thoughts on this, let me know if there is something need to be changed.

rustbot · 2026-07-05T13:28:23Z

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann, @JonathanBrouwer

rustbot · 2026-07-05T13:28:25Z

Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @folkertdev (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

@rustbot author: the review is finished, PR author should check the comments and take action accordingly
@rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 75 candidates
Random selection from 22 candidates

JonathanBrouwer · 2026-07-07T20:38:56Z

(would like to take a look at this, this might take me a few days to get to, should have time to take a look on friday)

JonathanBrouwer

Haven't reviewed the full diff yet, will do so after these two comments are fixed, thanks :3

View changes since this review

JonathanBrouwer · 2026-07-10T14:05:32Z

   | ^^^^^^^^^^^^^^^^---^^
   |                 |
-   |                 didn't expect any arguments here
+   |                 valid arguments are `always` or `never`


This change is not correct, always does not take any arguments.
This error would suggest always(always) would be valid.
Please drop that commit

JonathanBrouwer · 2026-07-10T14:07:54Z

You made changes to tests that are not related to this PR, could you at the very least split these changes into individual commits, and preferably into separate PRs? It makes the diff hard to review

rustbot · 2026-07-10T14:08:26Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

tahadostifam · 2026-07-10T19:21:47Z

Thanks for your feedback, I've applied the new changes and removed irrelevant ones.

#[inline(always = 5)]
fn foo() {}

This now emits unexpected_args as you said:

error[E0565]: malformed `inline` attribute input
  --> /tmp/main.rs:14:1
   |
14 | #[inline(always = 5)]
   | ^^^^^^^^^----------^^
   |          |
   |          didn't expect any arguments here

Currently with rustc 1.98-nightly this compiles with no error:

#[inline(always = 1)]
#[inline(always = "a")]
fn foo() {}

#[inline(always = 1)]
fn bar() {}

#[inline(always = "b")]
fn baz() {}

#[inline(always(always))]
fn buz() {}

fn main() {}

(Only generates warning but compiles successfully)

All of those malformed cases are covered now, with my changes.

Also reviewed spans of diagnostics several times, but if there is still something that must be changed, let me know.

tahadostifam · 2026-07-31T14:21:53Z

Hi dear Jonathan.

I truly appreciate your time and consideration of reviewing this PR.
I think you're right, we better to keep them separate and add a finalize_check;
But I tried to merge them because of @jdonszelmann comment in the inline.rs file.

Now I'm working to separate them and add check for it.

JonathanBrouwer · 2026-07-31T14:24:30Z

Yeah that comment is very old from a time when finalize_check didn't exist yet :)

rustbot · 2026-07-31T22:13:48Z

Some changes occurred in compiler/rustc_hir/src/attrs

cc @jdonszelmann, @JonathanBrouwer

JonathanBrouwer · 2026-08-01T13:53:07Z

    }
+
+    fn finalize_check(cx: &FinalizeCheckContext<'_, '_>, attr_span: Span) {
+        if let Some((attr, span)) = find_attr!(cx.parsed_attrs, Inline(attr, span) => (attr, span))


This will match the first inline attribute, whether it is force or not.
I think it should work if you do

find_attr!(cx.parsed_attrs, Inline(attr, span) if !matches!(attr, InlineAttr::Force { .. }) => (attr, span)) ` *[View changes since the review](https://triagebot.infra.rust-lang.org/gh-changes-since/rust-lang/rust/158814/c47bb2f39658c00b109693df9611d7238bedf6fa..b1ad22425d157eb8968bb11ffda53dc422dd91a5)*

Can you add a uitest for both orders of the attributes? (So inline first and rustc_force_inline first)

I thought it's cleaner to have if !matches!(attr, InlineAttr::Force { .. }) separate. Shall I change it?

The meaning is different, this will select the first Inline and incorrectly if it is a Force attribute it does nothing. That means it will not output an error for:

#[rustc_force_inline] #[inline]

JonathanBrouwer · 2026-08-01T13:54:33Z

I think we're almost there now, thanks for the effort!

…k if it conflicts with Inline attribute

…-with-inline

rustbot · 2026-08-01T15:56:32Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

JonathanBrouwer

@bors r+ rollup
Thanks a lot!

View changes since this review

rust-bors · 2026-08-01T16:09:01Z

📌 Commit 98cc5dc has been approved by JonathanBrouwer

It is now in the queue for this repository.

tahadostifam · 2026-08-01T16:20:57Z

Thanks a lot, I truly appreciate your kindness and patience!❤️
Hope to have more contributions in the future.

JonathanBrouwer · 2026-08-01T16:21:56Z

Hope to see you around more as well, was awesome working with you <3

…uwer Rollup of 8 pull requests Successful merges: - #160262 (Library lock file maintenance) - #158548 (Move `std::io::copy` to `alloc::io`) - #158814 (Produce an error when `#[inline]` and `#[rust_force_inline]` are used together) - #160025 (Fix an edge case with `StepBy::nth` on non-fused iterators) - #160271 (Resolver: Introduce `CmRef` which has a speclative borrow variant for `CmRefCell`) - #160281 (Fix(lib/fs/tests): Avoid permission denials when cleaning up TempDirs in `set_get_permissions_nofollows*`) - #160325 (tidy: Check `proc_macro_deps.rs` by reading it, not by including it) - #160334 (Add regression test for unused_allocation on boxed comparison)

@hkalbasi

Rollup merge of #158814 - tahadostifam:taha_refactors_rustc_attr_parsing, r=JonathanBrouwer Produce an error when `#[inline]` and `#[rust_force_inline]` are used together ### Merged RustcForceInline & Inline Attribute Parsers I've been reading [https://github.com/rust-lang/rust/issues/153101](https://github.com/rust-lang/rust/issues/153101), #131229 and I came across with this comment in `compiler/rustc_attr_parsing/src/attributes/inline.rs`: ```rust // FIXME(jdonszelmann): merge these two parsers and error when both attributes are present here. // note: need to model better how duplicate attr errors work when not using // SingleAttributeParser which is what we have two of here. ``` Having separate `SingleAttributeParser` implementations for `#[rustc_force_inline]` and `#[inline(...)]` meant the compiler wasn't able to recognize cases where both of them were used together on the same item, for example: ```rust #![feature(rustc_attrs)] #[rustc_force_inline] #[inline] fn foo() {} fn main() {} ``` <img width="1222" height="915" alt="image" src="https://github.com/user-attachments/assets/69d4e3b0-bc21-4679-8f3d-017f9fe152fb" /> This case was previously considered allowed, which is not correct. My changes replace the distinct attribute parsers with a single unified `AttributeParser` implementation for `InlineParser`, handling both attributes together in a single pass. By consolidating the logic, the parser now tracks the state of both attributes side-by-side using an `AcceptMapping` and introduces a new session diagnostic, `InlineForceInlineConflict`, which is explicitly triggered in the `finalize` step if a user attempts to combine them. An added benefit of catching this conflict early during the parsing phase is that it prevents downstream validation passes (like `check_attr`) from triggering redundant errors on malformed or incorrectly placed attributes, which naturally cleans up and streamlines our compiler stderr output as reflected in the updated UI test baselines. **This is my very first PR on rustc**, and I am incredibly grateful to @hkalbasi, who heavily guided me through the codebase and helped make this change possible! Sincerely looking for your feedback and thoughts on this, let me know if there is something need to be changed.

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 Jul 5, 2026

rustbot assigned folkertdev Jul 5, 2026

This comment has been minimized.

Sign in to view

rustbot added has-merge-commits PR has merge commits, merge with caution. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 5, 2026

tahadostifam force-pushed the taha_refactors_rustc_attr_parsing branch from bd990d8 to 15b16bb Compare July 5, 2026 13:42

rustbot removed has-merge-commits PR has merge commits, merge with caution. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 5, 2026

tahadostifam marked this pull request as draft July 5, 2026 14:25

rustbot 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-review Status: Awaiting review from the assignee but also interested parties. labels Jul 5, 2026

tahadostifam force-pushed the taha_refactors_rustc_attr_parsing branch from 15b16bb to b2e4430 Compare July 5, 2026 14:43

tahadostifam marked this pull request as ready for review July 5, 2026 17:58

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 5, 2026

JonathanBrouwer assigned JonathanBrouwer and unassigned folkertdev Jul 7, 2026

JonathanBrouwer requested changes Jul 10, 2026

View reviewed changes

rustbot 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-review Status: Awaiting review from the assignee but also interested parties. labels Jul 10, 2026

tahadostifam force-pushed the taha_refactors_rustc_attr_parsing branch from 6df20c4 to 0f6e739 Compare July 10, 2026 17:54

This comment has been minimized.

Sign in to view

tahadostifam force-pushed the taha_refactors_rustc_attr_parsing branch from 0f6e739 to 9e86aa9 Compare July 10, 2026 18:59

rustbot 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-review Status: Awaiting review from the assignee but also interested parties. labels Jul 31, 2026

tahadostifam force-pushed the taha_refactors_rustc_attr_parsing branch from 1c8f102 to b2e3b4d Compare July 31, 2026 22:13

This comment has been minimized.

Sign in to view

tahadostifam commented Aug 1, 2026

View reviewed changes

Comment thread compiler/rustc_hir/src/attrs/data_structures.rs Outdated

JonathanBrouwer requested changes Aug 1, 2026

View reviewed changes

Comment thread compiler/rustc_attr_parsing/src/attributes/inline.rs Outdated

JonathanBrouwer reviewed Aug 1, 2026

View reviewed changes

Comment thread compiler/rustc_attr_parsing/src/attributes/inline.rs Outdated

tahadostifam force-pushed the taha_refactors_rustc_attr_parsing branch from b2e3b4d to b1ad224 Compare August 1, 2026 13:27

This comment has been minimized.

Sign in to view

JonathanBrouwer reviewed Aug 1, 2026

View reviewed changes

tahadostifam added 2 commits August 1, 2026 18:49

feat: add finalize_check to RustcForceInline attribute parser to chec…

5c2400b

…k if it conflicts with Inline attribute

test: added testcase ui/attributes/inline/rustc-force-inline-conflict…

98cc5dc

…-with-inline

tahadostifam force-pushed the taha_refactors_rustc_attr_parsing branch from b1ad224 to 98cc5dc Compare August 1, 2026 15:56

JonathanBrouwer approved these changes Aug 1, 2026

View reviewed changes

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

JonathanBrouwer changed the title ~~Merged RustcForceInline & Inline Attribute Parsers~~ Produce an error when #[inline] and #[rust_force_inline] are used together Aug 1, 2026

JonathanBrouwer mentioned this pull request Aug 1, 2026

Rollup of 8 pull requests #160348

Merged

rust-bors Bot merged commit 0489fb0 into rust-lang:main Aug 1, 2026
13 checks passed

rustbot added this to the 1.99.0 milestone Aug 1, 2026

Uh oh!

Uh oh!

Conversation

tahadostifam commented Jul 5, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Merged RustcForceInline & Inline Attribute Parsers

Uh oh!

rustbot commented Jul 5, 2026

Uh oh!

rustbot commented Jul 5, 2026

Uh oh!

This comment has been minimized.

JonathanBrouwer commented Jul 7, 2026

Uh oh!

JonathanBrouwer left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JonathanBrouwer Jul 10, 2026

Choose a reason for hiding this comment

Uh oh!

JonathanBrouwer Jul 10, 2026

Choose a reason for hiding this comment

Uh oh!

rustbot commented Jul 10, 2026

Uh oh!

This comment has been minimized.

tahadostifam commented Jul 10, 2026

Uh oh!

tahadostifam commented Jul 31, 2026

Uh oh!

JonathanBrouwer commented Jul 31, 2026

Uh oh!

rustbot commented Jul 31, 2026

Uh oh!

This comment has been minimized.

Uh oh!

Uh oh!

Uh oh!

This comment has been minimized.

JonathanBrouwer Aug 1, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JonathanBrouwer Aug 1, 2026

Choose a reason for hiding this comment

Uh oh!

tahadostifam Aug 1, 2026

Choose a reason for hiding this comment

Uh oh!

JonathanBrouwer Aug 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JonathanBrouwer commented Aug 1, 2026

Uh oh!

rustbot commented Aug 1, 2026

Uh oh!

JonathanBrouwer left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rust-bors Bot commented Aug 1, 2026

Uh oh!

tahadostifam commented Aug 1, 2026

Uh oh!

JonathanBrouwer commented Aug 1, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

tahadostifam commented Jul 5, 2026 •

edited by rustbot

Loading

JonathanBrouwer left a comment •

edited by rustbot

Loading

JonathanBrouwer Aug 1, 2026 •

edited by rustbot

Loading

JonathanBrouwer Aug 1, 2026 •

edited

Loading

JonathanBrouwer left a comment •

edited by rustbot

Loading