Skip to content

Rewrite inline attribute parser to use new infrastructure and improve diagnostics for all parsed attributes #138165

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

jdonszelmann
Copy link
Contributor

@jdonszelmann jdonszelmann commented Mar 7, 2025

r? @oli-obk

This PR:

Builds on top of #138164

Closes #137950

@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 Mar 7, 2025
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@@ -584,7 +546,6 @@ fn codegen_fn_attrs(tcx: TyCtxt<'_>, did: LocalDefId) -> CodegenFnAttrs {
return OptimizeAttr::Default;
};

inline_span = Some(attr.span());
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 fixes #137950

@jdonszelmann jdonszelmann force-pushed the inline branch 2 times, most recently from e6dad01 to 2a707bf Compare March 9, 2025 15:34
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Collaborator

bors commented Mar 11, 2025

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

@oli-obk oli-obk 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 Apr 28, 2025
@jdonszelmann jdonszelmann force-pushed the inline branch 2 times, most recently from b7dda57 to 88a713a Compare June 9, 2025 22:40
@rust-log-analyzer

This comment has been minimized.

@jdonszelmann
Copy link
Contributor Author

@rustbot review

@rustbot 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 Jun 9, 2025
@rust-log-analyzer

This comment has been minimized.

@jdonszelmann
Copy link
Contributor Author

ah shit, broke clippy 😭

@jdonszelmann jdonszelmann force-pushed the inline branch 2 times, most recently from 3446ca2 to dda1c4a Compare June 10, 2025 22:28
@rust-log-analyzer

This comment has been minimized.

@jdonszelmann
Copy link
Contributor Author

ugh, the rebase

@bors
Copy link
Collaborator

bors commented Jun 12, 2025

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

@jdonszelmann jdonszelmann force-pushed the inline branch 2 times, most recently from 7034a27 to 8bbe2e0 Compare June 12, 2025 11:37
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jun 12, 2025
…ra, r=oli-obk

Infrastructure for lints during attribute parsing, specifically duplicate usages of attributes

r? `@oli-obk`

This PR adds a new field to OwnerInfo to buffer lints which are generated during attribute parsing and ast lowering in general. They can't be emitted at this stage because at that point there's no HIR yet, and early lints are already emitted.

This also adds the generic `S: Stage` to attribute parsers. Currently we don't emit any lints during early attribute parsing, but if we ever want to that logic will be different. That's because there we don't have hir ids yet, while at the same time still having access to node ids and early lints. Even though that logic isn't completely there in this PR (no worries, we don't use it), that's why the parameter is there.

With this PR, we also add 2 associated consts  to `SingleAttributeParser`. Those determine what logic should be applied when finding a duplicate attribute.

This PR was getting pretty large, so the first code using this logic is in rust-lang#138165. This code is all new things that weren't possible before so it also doesn't break any behaviour. However, some of it will be dead code right now. I recommend reviewing both before merging, though in some sense that doubles the size of the review again, and the other PR might be more controversial. Let me know how you want to do this `@oli-obk`
bors added a commit that referenced this pull request Jun 12, 2025
Infrastructure for lints during attribute parsing, specifically duplicate usages of attributes

r? `@oli-obk`

This PR adds a new field to OwnerInfo to buffer lints which are generated during attribute parsing and ast lowering in general. They can't be emitted at this stage because at that point there's no HIR yet, and early lints are already emitted.

This also adds the generic `S: Stage` to attribute parsers. Currently we don't emit any lints during early attribute parsing, but if we ever want to that logic will be different. That's because there we don't have hir ids yet, while at the same time still having access to node ids and early lints. Even though that logic isn't completely there in this PR (no worries, we don't use it), that's why the parameter is there.

With this PR, we also add 2 associated consts  to `SingleAttributeParser`. Those determine what logic should be applied when finding a duplicate attribute.

This PR was getting pretty large, so the first code using this logic is in #138165. This code is all new things that weren't possible before so it also doesn't break any behaviour. However, some of it will be dead code right now. I recommend reviewing both before merging, though in some sense that doubles the size of the review again, and the other PR might be more controversial. Let me know how you want to do this `@oli-obk`
@jdonszelmann jdonszelmann marked this pull request as ready for review June 12, 2025 23:12
@rustbot
Copy link
Collaborator

rustbot commented Jun 12, 2025

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

These commits modify tests/rustdoc-json.
rustdoc-json is a public (but unstable) interface.

Please ensure that if you've changed the output:

  • It's intentional.
  • The FORMAT_VERSION in src/librustdoc-json-types is bumped if necessary.

cc @aDotInTheVoid, @obi1kenobi

Some changes occurred in diagnostic error codes

cc @GuillaumeGomez

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

@bors
Copy link
Collaborator

bors commented Jun 13, 2025

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

Comment on lines -196 to 199

/// Represents `#[stable]`, `#[unstable]` and `#[rustc_allowed_through_unstable_modules]`.
Copy link
Contributor

Choose a reason for hiding this comment

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

imo we should keep the empty line for consistency with the other variants.

@@ -188,12 +188,14 @@ pub enum AttributeKind {
/// Represents [`#[doc]`](https://doc.rust-lang.org/stable/rustdoc/write-documentation/the-doc-attribute.html).
DocComment { style: AttrStyle, kind: CommentKind, span: Span, comment: Symbol },

/// Represents `#[inline]`.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
/// Represents `#[inline]`.
/// Represents `#[inline]` and `#[rustc_force_inline]`.

Comment on lines +107 to +108
Single<InlineParser>,
Single<RustcForceInlineParser>,
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this be a single parser, just a impl AttributeParser for InlineParser that handles both of them? Also we currently don't raise an error for

#[inline(never)]
#[rustc_force_inline]
fn blah(){}

and i think we should.

pub(crate) fn expected_string_literal(
&self,
span: Span,
actual_literal: Option<&MetaItemLit>,
Copy link
Contributor

Choose a reason for hiding this comment

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

"actual" is a bit ambiguous IMO

Suggested change
actual_literal: Option<&MetaItemLit>,
found: Option<&MetaItemLit>,

(Or, found_literal, perhaps)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-rustdoc-json Area: Rustdoc JSON backend 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Diagnostics error in interaction between #[optimize(..)] and #[no_sanitize(..)]
9 participants