Hacker News Reader

Comment by jwilm | Hacker News Reader

> How has it helped? Does it just keep the code clean or has it found mistakes and stuff like that too?

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.

View on HN

Nice to know, thanks!

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.

I'd really like to use clippy, but for production use I don't want to use anything but the stable Rust channel, whereas clippy apparently needs nightly Rust. Maybe I'm being overly cautious (OneSignal seems to do fine with just version pinning), but there's a reason nightly is separate from stable.

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?

We definitely have plans to get clippy working on stable Rust; though I will say, with clippy, using nightly is less of a big deal, since it's not something you depend on, it's a tool you use.

> if I could configure cargo to only use nightly Rust when invoking clippy,

This is

    rustup run nightly cargo clippy

    cargo +nightly clippy

if you have rustup installed.

Hey steve,

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

That's totally fair; I've gotten lucky, I think, with the mis-matches. As mentioned, we certainly want to ship a "known good" one to address exactly what you're talking about, but until then, it's not _super_ onerous to use, IMHO.

To be clear, clippy can't ever be a true "stable" crate. What clippy does is rely on a whole ton of compiler internals so that it does not have to reimplement the compiler. These internals change, because the rust compiler is under active development.

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.

`rustup component add clippy`

Whoa, that's the first I've heard about this. Very exciting plans!

Ballpark ETA on being able to install a precompiled clippy with rustup like that?

It's "phase 2" of https://internals.rust-lang.org/t/rust-ci-release-infrastruc...

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.

Yeah, clippy is a bit of an outlier because it hooks into the compiler itself to extract information during compilation. These are APIs that will never be "stable", nor are they really part of the "stdlib"; it's just that they're around and accessible in a nightly compiler.

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.

:) There is one way to have clippy work in the stable compiler: The integration of useful tools!

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

Not sure what you're trying to say here (you seem to be using sarcasm but I'm not sure), though I will note that clippy is wedded to a lot of compiler internals, so being a part of the compiler build/CI is a good thing for clippy. Often APIs get removed or changed from the compiler internals and we have to work around or sometimes revert it. Usually it works out, but it would be nice if the concern of having to support clippy's use case was part of the decision of how an API is to be changed. In the opposite direction, rustc does lints already and clippy is an extension of that. So I'm not really sure if "separation of concerns" is an issue here -- they're really the same concerns. While a lot of the clippy contributors are not well versed with compiler internals, the clippy maintainers all basically have to be, and we often have to dig deep into compiler changes to make stuff work with nightlies.

I don't see any reason why a set of stable APIs couldn't be defined, after all other languages do have them for the same purpose as clippy, e.g. Go vet, .NET Roslyn....

A set of stable APIs could be defined, but it would probably remove some of the more powerful lints in clippy.

You have the same issue with clang -- libclang is stable, but a lot of the plugins use the unstable clang plugin API.

I just meant that if a tool/lints have proven to be useful, why not internalize them into the compiler?

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.

I personally find it strange to develop on different branch than on your production system. "Works fine on my machine" is already well-known joke.

I've seen a lot of folks using nightly only for clippy and stable for everything else. Almost everyone has CI for both nightly and stable. It usually works out. If you're only using stable features, rust nightly is basically the same as stable with some speed improvements and clippy. This rarely, if ever, affects how something will work. If anything, you have a higher propensity for hitting bugs locally because the nightly compiler could be buggy.

Nigtly is nightly for a reason :)

Reply on news.ycombinator.com