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

Per-crate-type [lint] configuration #15046

Open
Nemo157 opened this issue Jan 10, 2025 · 1 comment
Open

Per-crate-type [lint] configuration #15046

Nemo157 opened this issue Jan 10, 2025 · 1 comment
Labels
A-lints Area: rustc lint configuration C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

Comments

@Nemo157
Copy link
Member

Nemo157 commented Jan 10, 2025

Problem

As mentioned in the original tracking issue

Some lints are crate specific, like only wanting missing_docs and missing_debug_implementations for [lib]s (#12115 (comment))

Having to add an #![allow(missing_docs)] to every test crate because they don't have any crate-level docs is annoying. The alternative of still using an in-code #![warn(missing_docs)] in src/lib.rs misses out on the benefits of a workspace-level lint config, like forgetting to add it to a new crate.

Proposed Solution

Being able to somehow configure different sets of lints for lib, bin, test, etc. crates.

Notes

No response

@Nemo157 Nemo157 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 Jan 10, 2025
@epage epage added the A-lints Area: rustc lint configuration label Jan 10, 2025
@epage
Copy link
Contributor

epage commented Jan 10, 2025

For myself, I've been setting things like this in my lib.rs. For clippy, they tend to either check for --cfg test or have a setting to check for it to avoid lints that aren't relevant for tests. The problem I found is that tests aren't the only thing I want to skip some lints on. For example, I don't want clippy::print_stdout on build scripts or examples. I use an updateable project templateto propagate these though my process isn't as automatic for workspace members but that is broader than [lints]

For missing_docs, I think that only fires for pub, so I just avoid that (I also have unreachable_pub set).

As for the idea to make per-build-target-type lints tables

  • We currently have no precedence for this but T-testing-devex is interested in adding build-target defaults tables so test.harness = false can be set more easily
  • We don't have precendence for [lints] overrides yet though people want it between workspaces and packages
  • Build scripts aren't build targets but are off on their own
  • I generally want to be careful in what complexity we add to manifests and not go overboard with fine-grained customization. We'll have to see as this gets explored where this lands

@epage epage added S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. and removed S-triage Status: This issue is waiting on initial triage. labels Jan 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lints Area: rustc lint configuration C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Projects
None yet
Development

No branches or pull requests

2 participants