Skip to content

Conversation

@JonathanBrouwer
Copy link
Contributor

@JonathanBrouwer JonathanBrouwer commented Nov 22, 2025

The goal of this PR is to make the eval_config_entry not have any side effects, by moving the check-cfg lints to the attribute parsing. This also helps ensure we do emit the lint in situations where the attribute happens to be parsed, but never evaluated.

cc @jdonszelmann @Urgau for a vibe check if you feel like it

@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-meta Area: Issues & PRs about the rust-lang/rust repository itself 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. labels Nov 22, 2025
@rust-log-analyzer

This comment has been minimized.

@Urgau
Copy link
Member

Urgau commented Nov 22, 2025

Does it mean we would get warnings for non-active cfg attributes?

#[cfg(target_os = "lol")] // warn and not active 
#[cfg(unknown)] // currently doesn't warn, since above is not active, but will it with this PR?
fn foo() {}

Regarding the non-accessible TyCtxt, would it be possible to continue to buffer the lint in ParseSess::buffered_lints, using sess.parse_sess.buffer_lint? Or is the problem that you don't emit the lint as a builtin lint and as such no longer have access to TyCtxt?

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@JonathanBrouwer
Copy link
Contributor Author

JonathanBrouwer commented Nov 25, 2025

Attributes that are configured out (like in your example) are currently not parsed, and therefore this would not cause this warning, preserving the old behavior. I didn't think of this edgecase so I'll make sure to add a test for this.

Indeed currently attribute lints are special and not emitted as a builtin lint. I'm gonna play around with this a bit and see if anything is stopping me from changing that

Zalathar added a commit to Zalathar/rust that referenced this pull request Nov 28, 2025
…r=Urgau

Run `eval_config_entry` on all branches so we always emit lints

Fixes rust-lang#149090

Ideally I'd have liked to fix this issue using rust-lang#149215, and this is still the long term plan, but this is slightly more annoying to implement than I'd have liked to, and this is also a nice and easy solution to the problem.

r? `@tgross35`
rust-timer added a commit that referenced this pull request Nov 28, 2025
Rollup merge of #149380 - JonathanBrouwer:cfg_select_lints, r=Urgau

Run `eval_config_entry` on all branches so we always emit lints

Fixes #149090

Ideally I'd have liked to fix this issue using #149215, and this is still the long term plan, but this is slightly more annoying to implement than I'd have liked to, and this is also a nice and easy solution to the problem.

r? `@tgross35`
RalfJung pushed a commit to RalfJung/miri that referenced this pull request Nov 28, 2025
Run `eval_config_entry` on all branches so we always emit lints

Fixes rust-lang/rust#149090

Ideally I'd have liked to fix this issue using rust-lang/rust#149215, and this is still the long term plan, but this is slightly more annoying to implement than I'd have liked to, and this is also a nice and easy solution to the problem.

r? `@tgross35`
@bors
Copy link
Collaborator

bors commented Nov 28, 2025

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

github-actions bot pushed a commit to rust-lang/rust-analyzer that referenced this pull request Dec 1, 2025
Run `eval_config_entry` on all branches so we always emit lints

Fixes rust-lang/rust#149090

Ideally I'd have liked to fix this issue using rust-lang/rust#149215, and this is still the long term plan, but this is slightly more annoying to implement than I'd have liked to, and this is also a nice and easy solution to the problem.

r? `@tgross35`
bors added a commit that referenced this pull request Dec 2, 2025
…elmann

Move even more early buffered lints to dyn lint diagnostics

Follow-up to #145881 and #145747.

I originally wanted to migrate most if not the entire rest of the early buffered lints. However, when trying to migrate the buffered lints used by check-cfg I encountered a roadblock. Namely, it depends on `TyCtxt` (well, `Option<TyCtxt>`) which makes it quite hard to migrate (see also #147634 (comment), #147634 (comment) & #149215).

So for now, I won't migrate it (maybe #149215 will find a solution), nor will I migrate the rest since it's quite tedious to migrate these. I'll leave them for future me.
@bors
Copy link
Collaborator

bors commented Dec 5, 2025

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

@JonathanBrouwer JonathanBrouwer added the S-blocked Status: Blocked on something else such as an RFC or other implementation work. label Dec 5, 2025
@JonathanBrouwer
Copy link
Contributor Author

JonathanBrouwer commented Dec 5, 2025

Rebased on #149662

After that PR, this change becomes trivial, we don't need to move the lints and we have access to TyCtxt

@JonathanBrouwer JonathanBrouwer changed the title Move check-cfg lints to rustc_attr_parsing Emit check-cfg during attribute parsing rather than evaluation Dec 5, 2025
@JonathanBrouwer JonathanBrouwer changed the title Emit check-cfg during attribute parsing rather than evaluation Emit check-cfg lints during attribute parsing rather than evaluation Dec 5, 2025
@jdonszelmann jdonszelmann self-assigned this Dec 5, 2025
@Urgau Urgau self-assigned this Dec 5, 2025
Copy link
Member

@Urgau Urgau left a comment

Choose a reason for hiding this comment

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

Looks good to me. Thanks for making it impossible to miss the check-cfg diagnostics.

View changes since this review

jhpratt added a commit to jhpratt/rust that referenced this pull request Dec 6, 2025
…nszelmann

Move attribute lints to `rustc_lint`

This PR changes two things:
- This decouples the `AttributeLintKind` from the `Lint` it is emitted in. `cx.emit_lint` now takes both as an argument, rather than inferring the `Lint` from the `AttributeLintKind`. This is nice because:
  - It allows us to remove `AttributeLintKind::InvalidMacroExportArguments`
  - It allows us to move the choice between `USELESS_DEPRECATED` and `UNUSED_ATTRIBUTES` out of the lint emitting code
  - It allows the next change:
- This moves `AttributeLintKind` to `rustc_lint_defs`, and the decorating code to `rustc_lint`. This is nice because:
  - It allows attribute lint decorating code to access the TypeCtxt, which unblocks rust-lang#149215
  - It might allow most early buffered attribute lints to become dyn lint diagnostics in the future, as in rust-lang#147634
  - It deduplicates `IllFormedAttributeInput`

This PR does not change observable output of the compiler, as can be seen by no uitests being affected.

r? `@jdonszelmann`
rust-timer added a commit that referenced this pull request Dec 6, 2025
Rollup merge of #149662 - JonathanBrouwer:lint-rework, r=jdonszelmann

Move attribute lints to `rustc_lint`

This PR changes two things:
- This decouples the `AttributeLintKind` from the `Lint` it is emitted in. `cx.emit_lint` now takes both as an argument, rather than inferring the `Lint` from the `AttributeLintKind`. This is nice because:
  - It allows us to remove `AttributeLintKind::InvalidMacroExportArguments`
  - It allows us to move the choice between `USELESS_DEPRECATED` and `UNUSED_ATTRIBUTES` out of the lint emitting code
  - It allows the next change:
- This moves `AttributeLintKind` to `rustc_lint_defs`, and the decorating code to `rustc_lint`. This is nice because:
  - It allows attribute lint decorating code to access the TypeCtxt, which unblocks #149215
  - It might allow most early buffered attribute lints to become dyn lint diagnostics in the future, as in #147634
  - It deduplicates `IllFormedAttributeInput`

This PR does not change observable output of the compiler, as can be seen by no uitests being affected.

r? `@jdonszelmann`
@JonathanBrouwer JonathanBrouwer marked this pull request as ready for review December 6, 2025 09:39
@rustbot
Copy link
Collaborator

rustbot commented Dec 6, 2025

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann

Some changes occurred in compiler/rustc_hir/src/attrs

cc @jdonszelmann

@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 Dec 6, 2025
@JonathanBrouwer
Copy link
Contributor Author

The PR is ready to be merged now :)

@JonathanBrouwer JonathanBrouwer removed the S-blocked Status: Blocked on something else such as an RFC or other implementation work. label Dec 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-attributes Area: Attributes (`#[…]`, `#![…]`) A-meta Area: Issues & PRs about the rust-lang/rust repository itself 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.

6 participants