ericseppanen / cargo-cranky Goto Github PK

Like deny, forbid turns lints into errors; unlike deny, however, forbid cannot be overridden.
https://doc.rust-lang.org/rustc/lints/levels.html

For projects or organizations that want to take a "hardline" stance on certain lints (e.g. unsafe_code), having cargo-cranky support the forbid lint level could be very important.

(NB: There's also a force-warn lint level that is a non-overridable counterpart to warn, and may also be desirable in some instances.)

When I run cranky within a directory of a member of a workspace, I get errors for all the other members of the workspace. With clippy, running in a member will produce results only for that workspace member.

"Multiple config files" might be a can of worms, but I could see a few different ways this could be useful:

• I have a set of aggressive lints I usually use, but I have one crate that needs to disable a few of those because they're just not appropriate for this crate.
• I have a standard set of lints I use for everything, but my projects don't share a common filesystem tree so I'd like my Cranky.toml file to live in my home directory.

Maybe this could be supported by having a "fall_through = true" config flag in Cranky.toml; when found we keep searching for additional Cranky.toml files (and merge their contents intelligently). And then when we reach the filesystem root we check in ~/.Cranky.toml also.

I would like to be able to write:

$ cargo cranky --add cast_possible_truncation

and have it automatically added to the Cranky.toml file (as a warn).

Guessing this tool won't be very relevant anymore now that Cargo has native support for lint configuration in 1.74. So I just want to say thank you for all the time and effort you've helped me save with this great tool!

Similar to what was mentioned in #3 (comment), but a little different. Perhaps that issue exists because this is just impossible.

I'd like to be able to use this tool, but with a blanket set of fairly "aggressive" rules across an entire organization.

Sometimes, like in the case of clippy::print_stdout this is appropriate for most projects (encourage folks to use the log crate), but I may want to disable it fro a CLI tool. Ideally I'd like to not have to adjust the project or workspace level Cranky.toml (since it may be automated). So, i'm hoping there would be a way to set an override from an in-code attribute, since that seems the most reasonable place to have such a thing...

See also https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Have.20in-code.20lint.20attributes.20have.20higher.20precidence.20than.20.2E.2E.2E/near/291373867

Thanks for cargo cranky!

There are lints outside of clippy that I often enable, for instance:

    "-Dunsafe_code",
    "-Wfuture_incompatible",
    "-Wnonstandard_style",
    "-Wrust_2018_idioms",
    "-Wrustdoc::missing_crate_level_docs",
    "-Wsemicolon_in_expressions_from_macros",
    "-Wtrivial_casts",
    "-Wtrivial_numeric_casts",
    "-Wunused_extern_crates",
    "-Wunused_import_braces",

It would be wonderful if Cranky could handle these non-clippy lints as well, as then it would be a very good solution to rust-lang/cargo#5034

Currently I enable clippy and non-clippy lints in .cargo/config.toml (https://github.com/emilk/egui/blob/e76c919c7e70c208c9a6209b9fe3369e7b6db99d/.cargo/config.toml) but it is a bit of a hack and has some problems (emilk/egui#1439).

If I use a new clippy lint in Cranky.toml, but someone else hasn't moved to that Rust version yet, they will get an "unknown lint" error.

If I don't want to bump the crate's minimum supported Rust version, I should be able to add that lint anyway-- and cargo cranky should be able to observe what stable release I'm on and disable lints that are too new.

Would this require hardcoding a list of clippy lints and the version when they landed? That sounds a bit hard to keep up with.

Currently if I put "rustdoc::missing_crate_level_docs" in warn in Cranky.toml it does nothing.

…though honestly I don't understand the rustdoc lints. cargo clippy -- -D rustdoc::missing_crate_level_docs runs without warnings when there are missing crate level docs.

Recently I was getting annoyed at how many metadata files are in the root of my workspace. To combat this issue it feels like tooling that is completely cargo-focused like this should really be storing its configuration in the Cargo.toml. The example from the readme could look like:

[workspace.metadata.lints]
warn = [
  "clippy::empty_structs_with_brackets",
  "clippy::cast_possible_truncation",
]

This could also support some of the usecases from #3 easily. The lints could be merged from workspace.metadata.lints and package.metadata.lints to support crate-specific overrides.

Hey,

Thanks for this crate, very useful.
I might be doing something wrong but from the README, I guessed the settings name changed to rust-analyzer.check.command but setting it like so:

{
 "rust-analyzer.check.command": "cranky",
}

Was not working, no errors but I wasn't getting inline warnings and errors from cranky.

The following did:

  "rust-analyzer.check.overrideCommand": [
        "cargo",
        "cranky",
        "--workspace",
        "--message-format=json",
        "--all-targets"
    ]

I don't know if it is possible but all my projects maintain slightly adjusted lint rules for doc-tests, specifically:

#![doc(test(attr(deny(future_incompatible, rust_2018_idioms, warnings))))]
#![doc(test(attr(allow(unused_extern_crates, unused_variables))))]

Ideally this tool would be able to provide that as well but I feel like that is probably not possible.