3 ms·
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 "stab
by Manishearth 10y ago
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.
- yazaddaruvala 10y ago:) 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
- Manishearth 10y agoNot 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.
- pjmlp 10y agoI 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....
- Manishearth 10y agoA 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.
- yazaddaruvala 10y agoI 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.
- EugeneOZ 10y agoI personally find it strange to develop on different branch than on your production system. "Works fine on my machine" is already well-known joke.
- Manishearth 10y agoI'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.
- EugeneOZ 10y agoNigtly is nightly for a reason :)