davidpdrsn
Weihang Lo 🦀`[lints]` table in Cargo.toml has been stabilized. Try it on the latest nightly Rust!
https://doc.rust-lang.org/nightly/cargo/reference/manifest.html#the-lints-section
Dirkjan Ochtman@weihanglo I noted that there's nothing in the documentation on why this is useful. I think it is because you can use it in a workspace-level Cargo manifest, as a way of managing the lint levels across crates, is that right?
Ed PageAs you mentioned, you can keep your lints in-sync across all of your packages within a workspace. However, this also let's you keep all of your crates in-sync within a package (lib, main, tests, etc). Currently, either of those can only be done with RUSTFLAGS which has its own problems.
@epage @weihanglo oh yeah, crates within a package! Will be nice to have this.
Zac@djc @epage @weihanglo Personally, I have a project with a huge number of crates that are basically individual example programs to help teach rust concepts to people (but not good enough to publish, sorry). This will help me by making it significantly easier to copy & paste my examples, and eliminate 7 identical lines across ~50 files.
I imagine this scenario could be extrapolated to plenty of similar circumstances. I'm looking forward to this feature.
Aria Desires@weihanglo @ekuber huh neat, does pulling this stuff out of the source code enable anything new or is it just a stylistic choice for people who don't like #[allow]?
Noratrieb@Gankra @weihanglo @ekuber When specified in a package, it applies to every crate / build-target within that package (lib, tests, bins, examples), increasing consistency without duplication. You can then use workspace inheritance to have this spread throughout your workspace and not just duplicated in each package.
This was spawned by our need for it in cargo. We have a very specific clippy config and we just disable clippy in everything rather than duplicate it. Now, we don't have to.
@Gankra @weihanglo @ekuber This also unblocks cargo from having more warnings and its own lints. We are hesitant in adding any warning as users are stuck with it. The `[lints]` table will give us a place to control those, allowing us to add more.
See https://github.com/rust-lang/cargo/issues/12235 which includes a list of potential lints.
Zoe@weihanglo I literally gasped when I saw this!
Yuri Astrakhan@weihanglo @epage Awesome news! It does need a bit more documentation though, esp around workspaces. E.g. `[lints] workspace = true` works, but `lints.workspace = true` does not. And there seem to be no way to override workspace, e.g. `unsafe_code = "deny"` in workspace, but allow in a crate. Regardless, awesome addition!
@nyurik @weihanglo lints.workspace should work as that is just two ways in TOML of expressing something but it must go before any `[]` table. As for overriding, we left that for a future extension to get something stabilized.