I'm especially happy to see that they're using clippy. It's not a core piece of their infra like hyper, but it's still being used, which is nice.
How has it helped? Does it just keep the code clean or has it found mistakes and stuff like that too?
Loved the diagram, btw.
Clippy hasn't found any bugs in our code that I'm aware of, but it has been invaluable even so.
Clippy is really good at preventing bit-rot. When refactoring, it typically points out constructs that are no longer needed after other changes.
It's great for teaching how to write Rust effectively and succinctly. I've certainly learned a lot from it. One example lint in this area is using `for item in list` vs `for item in list.into_iter()`.
OnePush sets `#![cfg_attr(not(test), warn(result_unwrap_used))]` to make sure no `unwrap()`s are used in production code; all errors must be handled! `result_unwrap_used` has easily been the most valuable lint for us.
Yeah, clippy isn't solely for finding bugs -- a lot of the lints are about better style and cleaning up code, which often become useful after refactorings.
It would be cool if I could configure cargo to only use nightly Rust when invoking clippy, and use stable for all dev/test/prod builds. Do you happen to know if that's possible?
Given that clippy is a tool, not a dependency, folks aren't overly concerned about this -- it cannot infect dependency trees and only requires nightly for local development. Most people do `rustup run nightly cargo install clippy` followed by `cargo +nightly clippy` to run it locally without needing to change the default toolchain.
There are plans to distribute clippy as part of the rust "extended" distribution, so the stability issue will go away.
But that is clearly an awful idea. No one would like useful tools at the expense of "separation of concerns" and marginally increased compiler maintenance :P
This way the compiler has a marginal increment of maintenance effort but can remain flexible, change its internals at any point. It will also benefit users who for a multitude of reasons only want/need to use stable.
You have the same issue with clang -- libclang is stable, but a lot of the plugins use the unstable clang plugin API.
> if I could configure cargo to only use nightly Rust when invoking clippy,
This is
rustup run nightly cargo clippy
cargo +nightly clippy
Using clippy is not as straightforward as you put it because clippy and the latest nightly often are broken together. There would be much less hassle if it was a stable crate. Also no worries of backwards compatibility between stable/nightly.
- rg
The plan for "stable" clippy is to bundle it with releases, precompiled. It will still use the internal APIs, but from a user's perspective they just have to `rustup component add clippy` and it will magically work.
We've got a good idea of how it will happen, but the infra stuff has to happen first -- nobody wants to complicate the existing infra if it's going to go away.
I don't have a clear timeline on that. A few months I guess.
On clippy's side we don't need many changes to make this work.
Whoa, that's the first I've heard about this. Very exciting plans!