-
Notifications
You must be signed in to change notification settings - Fork 200
Are hlint's severities a bit too high in general? #1549
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Alternatively, we take hlint's severities as they are, and direct people to adjust them here when they complain 🤷 |
A tangent that it is somewhat unrelated, but also sounds like it could be relevant to the discussion here: I would also like to add that having hlint's diagnostic override a lot of other things that HLS displays, and having them pop up first, is quite annoying, given that in 99.9% of the cases I would prefer to see the compiler's output. This is especially bad for students/new learners, where I've seen an hlint diagnostic hide or make very hard to see a type error produced by the compiler, which will cause their code to not compile. |
That sounds like a HLS issue, maybe make an issue there? That sounds like it's a client behaviour, and it seems surprising that clients would let a non-error diagnostic appear before an error diagnostic. Of course, if we changed to take more of hlint's diagnostics then that problem would probably get worse, since hlint "error"s would compete with GHC's errors. |
Question: Are their any hlint lint that has severity of "error" by default? If no then the only case, HLS will show error is when someone explicitly add a "error" lint to Though I do think hlint's default suggestions/hints are too strong to be considered as warnings. If we moved all the default hints to Any thoughts on this? |
Yes, lots, e.g. https://github.com/ndmitchell/hlint/blob/master/data/hlint.yaml#L816 If it was only user-defined ones then I think we could get away with preserving the "error" status. But tbh looking at that I'm not sure I feel great about presenting "use readTVarIO instead of atomically . readTVar" to the user as an "error". |
Here's a concrete (but perhaps unpleasant proposal): align hlint's interpretation of severities with GHC's. That means:
|
There were 8 So if you want to map warning to info, and leave error alone, that should work fine now (and even with 8, they were fairly uncommon warnings around STM and Lens). |
Okay, that sounds good. Let's see if people complain :) |
I'm going to close this as "basically done". I don't know if you want to write some guidance about how people should choose severities for hints somewhere. |
HLS has historically reported all hlint diagnostics at "information" level. There is a proposal to instead respect hlint's severities. This seems nice, but putting hlint's diagnostics next to GHC's makes the severities for hlint seem a bit high overall.
I don't have a clear rubric, but it seems to me roughly that GHC's view of severities is something more like:
Whereas hlint's view seems more like:
... and then there are custom errors, which I think people probably want to be severe.
Having written this down, I now think that perhaps the best thing to do would be to:
Any thoughts?
The text was updated successfully, but these errors were encountered: