Skip to content
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

Lints table allows both - and _ separators, including allowing redundant entries. #13943

Open
epage opened this issue May 21, 2024 · 1 comment
Labels
A-edition-next Area: may require a breaking change over an edition A-lints Area: rustc lint configuration S-needs-team-input Status: Needs input from team on whether/how to proceed.

Comments

@epage
Copy link
Contributor

epage commented May 21, 2024

Today, you can do:

[lints.rust]
unexpected_cfgs = "warn"
unexpected-cfgs = "allow"

and the behavior is unspecified.

After #13913, you can also do

[lints.rust]
unexpected-cfgs = { level = "warn", check-cfg = ['cfg(foo, values("bar"))'] }

and you'll get an "unused manifest key" warning for check-cfg.

@epage epage added A-lints Area: rustc lint configuration A-edition-next Area: may require a breaking change over an edition S-needs-team-input Status: Needs input from team on whether/how to proceed. labels May 21, 2024
@epage
Copy link
Contributor Author

epage commented May 21, 2024

We talked about this in today's Cargo team meeting.

On the command-line, rustc accepts lint names with both _ and - and it normalizes them to _ which is considered the canonical name.

For lints.cargo, we had previously decided to only support rustc's canonical format of _ (#13837).

I propose that we deprecate the use of - in lints and in a future edition (2027? we don't want to rush this for 2024), we remove support for - in lint names.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-edition-next Area: may require a breaking change over an edition A-lints Area: rustc lint configuration S-needs-team-input Status: Needs input from team on whether/how to proceed.
Projects
Development

No branches or pull requests

1 participant