User control over cargo warnings

[epage]

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

• [patch] in config.toml triggers unhelpful warnings #11782
• Publish size warnings (Bundle local images in rustdoc output rfcs#3397 (comment))
• cargo package should warn binary files by default #4413 (deny::detected-executable, deny::detected-executable-script)
• cargo publish should warn on invalid categories/keywords #4300
• Expand manifest validation for all settings #4377 (see also clippy::cargo_common_metadata)
• The "unused manifest key" warning doesn't print or halt the publishing with cargo publish #7380
• Warning when large binary files are included into the bundle #9058
• Warn on old build-directive syntax (Cannot extend build directives within cargo #11461)
• Control the warning from Warn when an edition 2021 crate is in a virtual workspace with default resolver #10910
• Warn in more cases than Warn when an edition 2021 crate is in a virtual workspace with default resolver #10910
• Lint againt non semver-open dependencies #5340 (see also clippy::wildcard_dependencies, deny::wildcard)
• Allow turning Cargo.toml warnings into errors #2568
• Maybe "cargo publish" should error if there are path overrides #2489
• Disable warning from path dependencies dependencies warning control, overriding path heuristic #8546
• Warn on mixed case package names (Publishing a crate is case-sensitive #6043)
• deprecate or warn about downloads over unencrypted HTTP #7081
• SPDX dual-license inconsistency #2039 (see also Restriction Lint: Crate License rust-clippy#3867, deny's licenses)
• warn if rerun-if-changed=PATH is used but PATH points to none-existing file #6003
• Add a warning when enabling LTO for crates with both cargo-types that support LTO and ones that don't. #4611
• Cargo will silently ignore invalid .cargo/config options #5890
• Add a way to check for duplicate dependencies #7285 (see also clippy::multiple_crate_versions, deny::duplicate)
• add a warning when compiling a user crate named core #7760
• Cargo allows you to have a different name in [lib] and [package] when publishing #6827
• Redundant package.homepage (see Add guidance on setting homepage in manifest #13293)
• clippy::negative_feature_names
• clippy::redundant_feature_names
• always inherit dependencies / never inherit dependencies (blocked on Poor interaction between workspace dependencies and default-features #12162?)
• always inherit workspace dependencies
• non-latest edition
• include patterns should report invalid paths #14390

Proposed Solution

As package and workspace level lint control, turning existing warnings into diagnostics where possible

Tasks

• rustc-like diagnostics for parsing Cargo.toml (feat: Add rustc style errors for manifest parsing #13172)
• Report what set the lint level (see Unused dependencies cleanup #13778 for context)
• im_a_teapot lint should be unstable (see Cleanup linting system #13797 for context) (implemented in Error when unstable lints are specified but not enabled #13805)
• Clean up forbid handling for default/edition level (see Cleanup linting system #13797 for context)
• Documentation of all supported lints similar to rustc and clippy (see Add tooling to document lints #14025)
• Needs a stable lint at the time of stabilization

Non-blocking

• rustc-like diagnostics for parsing Cargo.lock
• rustc-like diagnostics for parsing .cargo/config.toml
• Deciding how to handle edition compatibility groups and groups in general (since refactor: Remove rust_2024_compatibility lint group #13740 skipped it for 2024)
  • Should we reuse rustc groups or not?
• rustc-like diagnostics for processing Cargo.toml (ie port warnings off of shell.warn for consistency)
• Diagnostic summary

Open questions

• How many of the lints should be run as part of every cargo invocation vs run as part of an explicit "lint" step?
  • See https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Cargo.20Lints/near/389419039
• Do we share namespaces when appropriate?
  • See https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Sharing.20of.20lints/near/475872847

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.#

[epage]

From #10160 (comment)

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.

[epage]

imo we need structured diagnostics which we pass to the diagnostic system which will then be turned into errors or something else

[epage]

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

• Rename Config to Context (we might want to do this anyways)
• Refactor Context to allow decorating it (wrapping it)
• Whenever we start down a workspace or package specific code path, we decorate the Context with that workspace or package's lint configuration

[epage]

One 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?

[weihanglo]

Should we use cargo::rust_2024_compatibility group or should we key off of rust::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.

[epage]

Take unused_lints. iirc rust::unused_lints affects both rustc and clippy.

So the question would be

• Is rust::unused_lints global or specialized for rustc linters
• If not global, does that mean cargo::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?