Per-crate-type `[lint]` configuration

[Nemo157]

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

[epage]

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