Description
Is your enhancement request related to a problem? Please describe.
Right now, HLS exposes two level of diagnostics: error and warning. Some plugin (really few) also uses info and hint, but any diagnostic from GHC is always exposed as error or warning.
I would find interesting if we could leverage the different diagnostics categories.
Right now, when developing, my workflow is as such:
- Until there are still "error", I'm only focusing on "error" and ignoring warnings.
- Once there are no more "error", I'm fixing warnings.
However, some warnings are more alarming than other and I would like to be able to focus on making progress with my work in progress and have a clear view of what is going on without having to inspect all the warnings immediatly.
For example, I would qualified "unused import" as something not important right now: it have NO impact on the correctness on my code.
On the other hand, missing field in record initialization is clearly something I need to fix if I want to have chance to have a code which runs without runtime error.
Usage of "deprecated" code may not be something I want to see immediately, especially that such warning may stay in the codebase and come from something not relevant to my current workflow.
Describe the solution you'd like
I don't think there is a "fit all needs" classification of errors for everyone. Some developers are pretty happy with the usage of partial function in their codebase, when others want to fix all "name shadowing" issues immediately.
I'm hence wondering if each project could be associated with a way to map a specific diagnostic (either the GHC error code number, or the "name" of the diagnostic) to a diagnostic level.
This could be part of the hie.yaml file for example:
# Defined but not used
- GHC-40910: info
# Defaulting
- GHC-18042: hint
# Top level with no type signature
- GHC-38417: info
# Name shadowing
- GHC-63397]: info
Describe alternatives you've considered
All of that can be done in the user editor, provided that it comes with some scripting features. This would simplify HLS logic. However, it increases the entry level in project, especially if multiples editors are used in a project. For example, at work, most devs use VScode and some devs use neovim. As owner of the "dev experience", I would have to maintain a plugin for VScode (which represents 99% of our devs) and I'll obvious have to maintain the plugin for neovim (because that's what I use).
It could also be upstreamed to GHC directly: ask ghc to emit different level of diagnostics and allows a way to parametrize that (Similarly to the -Werror=foo or -Wwarn=bar which allows the promotion of warning foo as error or warning bar as warning.
This will actually be the best solution, but it requires changes in GHC. I will open a ticket, maybe there are some low hanging fruit here. (I'm thinking about all of that in the middle of this issue redaction, so I'll keep the issue for reference, but I may followup with a GHC ticket)