4 ms·
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
by Manishearth 10y ago
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.
- 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.