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

Turning existing warnings into lints:

• [patch] in config.toml triggers unhelpful warnings #11782
• Publish size warnings (Bundle local images in rustdoc output rfcs#3397 (comment))
• The "unused manifest key" warning doesn't print or halt the publishing with cargo publish #7380
• Control the warning from Warn when an edition 2021 crate is in a virtual workspace with default resolver #10910
• Allow turning Cargo.toml warnings into errors #2568

Porting clippy lints to cargo

• Expand manifest validation for all settings #4377 (see also clippy::cargo_common_metadata)
• Lint againt non semver-open dependencies #5340 (see also clippy::wildcard_dependencies, deny::wildcard)
• Warn when new duplicate dependencies are introduced #13899 (see also clippy::multiple_crate_versions, deny::duplicate)
• Lint for negative feature names #15581
• Lint for redundant feature names #15580

Examples of new lints:

• 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
• Warning when large binary files are included into the bundle #9058
• Warn on old build-directive syntax (Cannot extend build directives within cargo #11461)
• Warn in more cases than Warn when an edition 2021 crate is in a virtual workspace with default resolver #10910
• 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 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)
• Lint if workspace dependency inheritance isn't used #15578
• Lint if workspace lints are available but not inherited #15579
• non-latest edition
• include patterns should report invalid paths #14390
• warn if two dep info files within the same package point to the same source file (Spurious "error[E0583]: file not found for module" error. #7730).
• deny missing metadata when running cargo package cargo package (and publish) includes target folder #15398 (comment)

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