Skip to content

Conversation

@Bryntet
Copy link
Contributor

@Bryntet Bryntet commented Feb 8, 2026

Currently, to emit the errors, during codegen we iterate over all feasible targets that these attributes could be placed on, this PR changes it so that we just emit these errors in the check_attr step of attribute parsing, since this check is guaranteed to already iterate through all attributes, it should (I think), be a little bit faster to emit from there instead

@rustbot
Copy link
Collaborator

rustbot commented Feb 8, 2026

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 Feb 8, 2026
@rustbot
Copy link
Collaborator

rustbot commented Feb 8, 2026

r? @davidtwco

rustbot has assigned @davidtwco.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: compiler
  • compiler expanded to 21 candidates
  • Random selection from 12 candidates

@Bryntet
Copy link
Contributor Author

Bryntet commented Feb 8, 2026

might be good to do a perf run?

instead just check and emit this attribute error through `check_attr.rs`
@Bryntet Bryntet force-pushed the symbol-attrs-check branch from cdc764e to d1cb52c Compare February 8, 2026 23:51
@JonathanBrouwer
Copy link
Contributor

r? me

@rustbot rustbot assigned JonathanBrouwer and unassigned davidtwco Feb 9, 2026
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.

Given that I'd prefer to keep the code where it currently is, since this happening during codegen seems like the more logical place to me, sorry

View changes since this review

// if the `rustc_attrs` feature is not enabled, then the
// attributes we are interested in cannot be present anyway, so
// skip the walk.
if !tcx.features().rustc_attrs() {
Copy link
Contributor

Choose a reason for hiding this comment

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

Because of this check there shouldn't be any perf difference, this will be false for any realistic crate

@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 9, 2026
@rustbot
Copy link
Collaborator

rustbot commented Feb 9, 2026

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

@rustbot rustbot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Feb 9, 2026
@rust-bors
Copy link
Contributor

rust-bors bot commented Feb 9, 2026

☔ The latest upstream changes (presumably #152373) made this pull request unmergeable. Please resolve the merge conflicts.

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

4 participants