Open epage opened 1 year ago
From https://github.com/rust-lang/cargo/issues/10160#issuecomment-1573883951
Just had a talk with @Muscraft. This is mostly my idea but it would be great if we have this kind of error overhaul. It will help things like JSON format message (#8283) or developing Cargo's own lint rules with
-Zlints
(#12115). It would also open a door to diagonostics translation (rust-lang/rust#100717). Probably the modularization of Cargo could benefit from it as well.
imo we need structured diagnostics which we pass to the diagnostic system which will then be turned into errors or something else
An obvious way to implement this is to shove the lint config in and our of Config
as we enter and leave the relevant contexts. This is a bit more brittle and lowers our chances for doing some operations with threading as Config
needs to be mutable everywhere
One thought for how we could implement this
Config
to Context
(we might want to do this anyways)Context
to allow decorating it (wrapping it)Context
with that workspace or package's lint configurationOne thought I had from #13621 was more about the linting system as a whole.
Should we use cargo::rust_2024_compatibility
group or should we key off of rust::rust_2024_compatibility
group?
Should we use
cargo::rust_2024_compatibility
group or should we key off ofrust::rust_2024_compatibility
group?
What is the advantage of that? I can think of a better coherent view of lints. But if external tools don't know about cargo lints, then the behavior might be inconsistent. (Just an imaginary situation, don't know if they really exist.)
From another angle, it looks like Cargo goes beyond Cargo and starts overriding other tools' defaults. This might need a cross-team discussion.
Take unused_lints
. iirc rust::unused_lints
affects both rustc and clippy.
So the question would be
rust::unused_lints
global or specialized for rustc
linterscargo::unused_lints
should affect all Cargo.toml
linters (e.g. if we moved Cargo lints from clippy-driver
to cargo clippy
)Or put another way, does a user say "I want to see 2024 Edition compatibility warnings" or do they say "I want to see Rust 2024 Edition compatibility warnings separately from Cargo 2024 Edition compatibility warnings". The Edition is the same concept, so it seems weird to split it by tool. However, rustfmt does have a distinct Edition so maybe we should keep it more loose generally?
Problem
Today, cargo maintainers are very cautious as to what warnings are created because they cannot be turned off by the user when they are intended. The problem is we've not had a mechanism to control it. With #12115, we'll now have a mechanism
Items blocked on diagnostic control
11782
4413 (deny::detected-executable, deny::detected-executable-script)
4300
4377 (see also clippy::cargo_common_metadata)
7380
9058
5340 (see also clippy::wildcard_dependencies, deny::wildcard)
2568
7081
2039 (see also rust-lang/rust-clippy#3867, deny's licenses)
6003
4611
5890
7285 (see also clippy::multiple_crate_versions, deny::duplicate)
7760
6827
package.homepage
(see #13293)14390
Proposed Solution
As package and workspace level lint control, turning existing warnings into diagnostics where possible
Tasks
Cargo.toml
(#13172)im_a_teapot
lint should be unstable (see #13797 for context) (implemented in #13805)rustc
andclippy
(see #14025)Non-blocking
Cargo.lock
.cargo/config.toml
Cargo.toml
(ie port warnings off ofshell.warn
for consistency)Notes
There will still be lints that are not related to the package but related to the user or / invocation. At a later stage, we can consider user-level lint levels.#