Skip to content

Conversation

@Bryntet
Copy link
Contributor

@Bryntet Bryntet commented Jan 18, 2026

Tracking issue: #131229

two more quick ones

r? @JonathanBrouwer

@rustbot
Copy link
Collaborator

rustbot commented Jan 18, 2026

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

Some changes occurred in compiler/rustc_hir/src/attrs

cc @jdonszelmann, @JonathanBrouwer

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

cc @jdonszelmann, @JonathanBrouwer

@rustbot 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 Jan 18, 2026
impl<S: Stage> NoArgsAttributeParser<S> for RustcOffloadKernelParser {
const PATH: &[Symbol] = &[sym::rustc_offload_kernel];
const ON_DUPLICATE: OnDuplicate<S> = OnDuplicate::Error;
const ALLOWED_TARGETS: AllowedTargets = AllowedTargets::AllowList(&[Allow(Target::ForeignFn)]);
Copy link
Contributor

@JonathanBrouwer JonathanBrouwer Jan 18, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From #147936 it seems like Target::Fn should also be allowed. I don't think ForeignFn should be allowed. Note that an extern fn { ... } is still just a Target::Fn

This attribute does not seem to have a single test or usage in rustc which is fascinating

@Sa4dUs As the implementer of this attribute, what should the correct target list be? Only functions?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This attribute does not seem to have a single test or usage in rustc which is fascinating

I also found this fascinating, I thought that extern fn would be Target::ForeignFn

Copy link
Contributor

@JonathanBrouwer JonathanBrouwer Jan 18, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rust has two related concepts:

A normal function that is exported with an abi:

extern "ABI" fn thing {
    
}

A foreign function:

extern "ABI" {
    fn thing();
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, accepting only Target:Function should be the way to go. this attribute is currently used to adjust functions written in rust to be compatible with offload.

we'll add some tests using this attr soon :)

cc @ZuseZ4 in case you have in mind any case where we might want to mark a ForeignFn

Copy link
Member

@ZuseZ4 ZuseZ4 Jan 18, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this intrinsic it doesn't really make sense to support ForeignFn. It is there to run Rust code on a GPU.

Our other intrinsic, offload_args however only realy makes sense in combination with a ForeignFn. See e.g. https://github.com/rust-lang/rust/pull/150683/changes#diff-e92c562c10044d53fd41b1b06ef59a43087a6434e09fa8e667dea5b729d07726
However, I would expect that in most cases, people offload a safe wrapper around the ForeignFn (like I'm doing it in my test case there), instead of directly offloading the ForeignFn. So I think it should be fine to not allow ForeignFn at the moment, and only discuss it if users complain.

@rust-log-analyzer

This comment has been minimized.

@rust-bors

This comment has been minimized.

@Bryntet Bryntet force-pushed the port_rustc_codegen_attrs branch 3 times, most recently from ecc0410 to b52ecfe Compare January 18, 2026 22:16
@rustbot

This comment has been minimized.

@rust-bors

This comment has been minimized.

Copy link
Contributor

@JonathanBrouwer JonathanBrouwer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

r=me after solving conflicts
@bors rollup d+

View changes since this review

@JonathanBrouwer

This comment was marked as off-topic.

@JonathanBrouwer

This comment was marked as off-topic.

@rust-bors

This comment was marked as off-topic.

@JonathanBrouwer

This comment was marked as off-topic.

@rust-bors

This comment was marked as off-topic.

@JonathanBrouwer

This comment was marked as off-topic.

@rust-bors

This comment was marked as off-topic.

@JonathanBrouwer
Copy link
Contributor

@bors delegate

@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 19, 2026

✌️ @Bryntet, you can now approve this pull request!

If @JonathanBrouwer told you to "r=me" after making some further change, then please make that change and post @bors r=JonathanBrouwer.

@Bryntet Bryntet force-pushed the port_rustc_codegen_attrs branch from b52ecfe to 3e731f7 Compare January 19, 2026 09:41
@rustbot
Copy link
Collaborator

rustbot commented Jan 19, 2026

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.

@Bryntet
Copy link
Contributor Author

Bryntet commented Jan 19, 2026

@bors r=JonathanBrouwer

@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 19, 2026

📌 Commit 3e731f7 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 Jan 19, 2026
rust-bors bot pushed a commit that referenced this pull request Jan 19, 2026
…uwer

Rollup of 2 pull requests

Successful merges:

 - #151336 (Port rustc codegen attrs)
 - #151359 (compiler: Temporarily re-export `assert_matches!` to reduce stabilization churn)

r? @ghost
@rust-bors rust-bors bot merged commit a77d6b8 into rust-lang:main Jan 19, 2026
11 checks passed
@rustbot rustbot added this to the 1.95.0 milestone Jan 19, 2026
rust-timer added a commit that referenced this pull request Jan 19, 2026
Rollup merge of #151336 - port_rustc_codegen_attrs, r=JonathanBrouwer

Port rustc codegen attrs

Tracking issue: #131229

two more quick ones

r? @JonathanBrouwer
@Bryntet Bryntet deleted the port_rustc_codegen_attrs branch January 19, 2026 16:35
jhpratt added a commit to jhpratt/rust that referenced this pull request Jan 21, 2026
…onathanBrouwer

Port `#[patchable_function_entry]` to attr parser

This is the last codegen attr (see rust-lang#151335 and rust-lang#151336)!

Tracking issue: rust-lang#131229

currently this PR is rebased on rust-lang#151336 to make CI pass for the last commit

to see the actual changes in this PR you can look [here](https://github.com/rust-lang/rust/pull/151340/changes/3e731f7e84301a898a36e46ee5e4845ff9bda98a..55111fb468808b733e97170a841217a67666ac33)
rust-timer added a commit that referenced this pull request Jan 21, 2026
Rollup merge of #151340 - port_patchable_function_entry, r=JonathanBrouwer

Port `#[patchable_function_entry]` to attr parser

This is the last codegen attr (see #151335 and #151336)!

Tracking issue: #131229

currently this PR is rebased on #151336 to make CI pass for the last commit

to see the actual changes in this PR you can look [here](https://github.com/rust-lang/rust/pull/151340/changes/3e731f7e84301a898a36e46ee5e4845ff9bda98a..55111fb468808b733e97170a841217a67666ac33)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-attributes Area: Attributes (`#[…]`, `#![…]`) S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants