Skip to content

Conversation

@clubby789
Copy link
Contributor

@clubby789 clubby789 commented Dec 8, 2025

Split from #149791

cc @Urgau

@rustbot
Copy link
Collaborator

rustbot commented Dec 8, 2025

Some changes occurred in check-cfg diagnostics

cc @Urgau

@rustbot rustbot added 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 Dec 8, 2025
@rustbot
Copy link
Collaborator

rustbot commented Dec 8, 2025

r? @madsmtm

rustbot has assigned @madsmtm.
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

@joshtriplett
Copy link
Member

LGTM. r=me once CI passes.

@bors delegate+

@bors
Copy link
Collaborator

bors commented Dec 8, 2025

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

If @joshtriplett told you to "r=me" after making some further change, please make that change, then do @bors r=@joshtriplett

@rust-log-analyzer

This comment has been minimized.

//@ compile-flags: --check-cfg=cfg()
//@ run-rustfix

#[cfg(FALSE)]
Copy link
Member

Choose a reason for hiding this comment

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

This will not work on cases like "False" right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's correct - this is mostly based off of FALSE being a somewhat common idiom, while False is not

@jdonszelmann
Copy link
Contributor

jdonszelmann commented Dec 9, 2025

hm, have you seen @scrabsha's work on uppercase/lowercase suggestions in the parser? I think it'd be cool if we could suggest against all mis-capitalizations here and maybe do that in a general enough way that all attribute parsers can benefit from it instead of a cfg-specific lint. At least, could you take a quick look if we can re-use the parsing infra for it? I like it when the error messages are consistent :)

Copy link
Contributor

@jdonszelmann jdonszelmann left a comment

Choose a reason for hiding this comment

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

if that doesn't help let me know and I'll approve this version. The change is a good one.

View changes since this review

@rustbot 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 Dec 9, 2025
@rustbot
Copy link
Collaborator

rustbot commented Dec 9, 2025

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

@jdonszelmann jdonszelmann assigned jdonszelmann and unassigned madsmtm Dec 9, 2025
@jdonszelmann
Copy link
Contributor

@bors delegate-

@clubby789
Copy link
Contributor Author

clubby789 commented Dec 10, 2025

I've spent a while looking into this and I'm not sure it makes sense to factor out the exact machinery from parsing, especially as the attr parsing machinery is some distance from the check-cfg lint.
This check-cfg special case is to address the specific pattern of people using an obviously non-existent FALSE cfg, and to inform them that the new boolean literal syntax exists. Similarly, fake false and true expected cfg names to use the existing 'similar name' machinery in check-cfg would give us a more consistent but less specific error:

warning: unexpected `cfg` condition name: `FALSE`
  --> $DIR/false.rs:8:7
   |
LL | #[cfg(FALSE)]
   |       ^^^^^ help: there is a config with a similar name: `false`
   |
   = help: to expect this configuration use `--check-cfg=cfg(FALSE)`
   = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg.html> for more information about checking conditional configuration
   = note: `#[warn(unexpected_cfgs)]` on by default

warning: 1 warning emitted

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

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.

9 participants