3 ms·
It’s nice when you don’t have to worry about what linter you should be using because everyone uses the same static analysis to check for this sort of thing and
by dodobirdlord 4y ago
It’s nice when you don’t have to worry about what linter you should be using because everyone uses the same static analysis to check for this sort of thing and it lives in the compiler.
- pjmlp 4y agoYet, clippy does exist.
- tialaramex 4y agoAnd, as we saw in several previous threads: I don't think Clippy lints are an adequate substitute for correctness checks in the Rust compiler itself, plenty of people with more actual impact on Rust agree with me about that. In practice Clippy lints do get "promoted" in this way, though not always as quickly as I'd like. However, Clippy has lots of style lints which I'm sure some people would be very annoyed to see in the compiler itself. Do you want a Clippy lint telling you that you should do X, and not Y, just because it's considered stylistically better and even though it has literally no impact on the compiled result? So it makes sense to me that Clippy exists as a linter the problem is the abuse of linters for "Actually programs in this language are dumpster fires unless you obey these lints" and so far Rust is avoiding that.
- pjmlp 4y agoThen I suggest removing such tests out of clippy and integrate them into Rust, I am sure there are a couple that fail your goals. People can't even agree what unsafe is suposed to be used for, as certain groups misuse it for dependent types programing.
- tialaramex 4y agoSure, I'd like the _ = lock() lint to be an error for example, since you almost certainly didn't mean that, and if you did that's the least useful way to express it. But time is limited, perhaps I'll get to it at the weekend if nobody else has already done so.