Eyesores caused by overlapping warnings/errors

[santiweight]

Your environment

hls-1.0.0 on ubuntu (irrelevant afaik)

Which lsp-client do you use:
VS Code

Steps to reproduce

Code that causes the issue:

someFunc :: IO ()
someFunc = case [] of
    (1:1) -> error ""

When writing code that produces an error, hlint warnings are still returned along with the error. This makes it very hard to find errors and generally clutters the developer workspace. When an error is encountered, the common case is to focus on the error and not to apply linter hints, which are commonly applied after the code in question compiles.

Suggestion: filter out hlint warnings that intersect with the text span of an error.

Perhaps this isn't really possible, but for examples such as the image above, the issue is extremely pronounced and produces really bad eyesores quite commonly.

Note: some warnings, such as unused variables are useful during uncompiling code, but many of these will not intersect with errors, and many of those warnings that are useful will be redundant since only intersecting warnings are filtered.

[jneira]

This is a bad interaction between diagnostics from several sources, so maybe the right solution could be fix for all cases in hls-plugin-api itself.
An adhoc workaround could be make hlint does not emit warnings until ghc errors are gone, as suggested here: #579
But all plugins emitting diagnostics should adhere to that rule (there are only 2 sources of diagnostics for now, ghc and hlint, but threre would be additional ones in the future)

[santiweight]

The reason I am against your suggested fix (which is also the first thought that came to my mind) is because of reading some discussion regarding the error refactoring currently occurring in GHC. During that discussion, Richard Eisenberg brought up a good point that many warning are actually very helpful and even important in terms of debugging. The unused variable warnings is a good example or better yet name shadowing (which is a very frustrating class of debuggable for beginners).

I wonder whether HLint could help the issue by two levels of diagnostics:

• warning
• suggestion

so that we still get important warnings (such as unused variable or shadowed names) but omit refactoring suggestions.

My point is that not showing warnings at all isn't good enough imo and, while better, omits a big gain to be had from warnings.

[jneira]

Well, warnings will be shown after errors are fixed for sure. And you cant show properly both at same time in a clear way so the idea would be show them progressively in order of relevance: errors -> warnings -> suggestions.

[michaelpj]

I think the is also arguably the client's responsibility to decide how to show these.

[jneira]

I think the is also arguably the client's responsibility to decide how to show these.

Mmm, wise note as usual, yeah, the client should be able to filter diagnostics by type, does not vscode do it already?

[pepeiborra]

VSCode does this already, I routinely turn off info diagnostics while fixing errors

[santiweight]

Related reading:

ghc-proposals/ghc-proposals#411

[pepeiborra]

can we close this?