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

Workspace lints should have the option to be opt-out rather then opt-in #12984

Closed
Jasper-Bekkers opened this issue Nov 16, 2023 · 3 comments
Closed
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage.

Comments

@Jasper-Bekkers
Copy link

Jasper-Bekkers commented Nov 16, 2023

Problem

The newly introduced [lints] section has a fatal flaw for our codebase, which is that we define all of our lints in our root workspace, but then have to opt in, in every crate, to those lints through [lints] workspace = true.

This means, for us, that we need to audit the Cargo.toml files every code review to make sure we didn't accidentally miss adding this line to the toml file. This introduces an additional manual workflows: a reviewer manually needs to check that it's present. (It looks from #12174 that at least cargo new adds the line automatically)

Proposed Solution

Ideally we can force clippy lints for the entire workspace rather then having them be opt-in for every crate.

Currently we're using the rustflags hack to accomplish this and while I'd love to move away from it in due time, the 1.74 release unfortunately can't be the release that does this for us.

Notes

No response

@Jasper-Bekkers Jasper-Bekkers added C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage. labels Nov 16, 2023
@epage
Copy link
Contributor

epage commented Nov 16, 2023

Closing in favor of #12208 so we talk about if/how we want to handle implicit inheritance holistically, rather than piece-meal for each feature. If there is a reason we should keep this open separately, let us know!

@epage epage closed this as not planned Won't fix, can't repro, duplicate, stale Nov 16, 2023
@Jasper-Bekkers
Copy link
Author

Thanks @epage would you want me to comment on that issue to describe how we'd like to be using this?

@epage
Copy link
Contributor

epage commented Nov 16, 2023

Yes, that would be helpful

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

No branches or pull requests

2 participants