search

haskell / haskell-language-server

Official haskell ide support via language server (LSP). Successor of ghcide & haskell-ide-engine.
Apache License 2.0
2.61k stars 353 forks source link

Only report typed holes errors/warnings if no other errors remain #715

Open merijn opened 4 years ago

merijn commented 4 years ago

I often use typed holes while developing so I don't have to think about them while refactoring something. Unfortunately, ghcide (and most other tools) still flag the holes with warnings/errors unless you completely disable them. I think it would be great if you could (conditionally) make ghcide only report hole errors/warnings when all other issues have been fixed so they don't interrupt refactoring attempts with pointless noise.

(Actually, writing this I realise it might be even better to generalise this to entire sets of warnings that should only be reported when everything else is fixed, which could then include things like unused names/imports, but this might only be feasible after GHC finally gets structured error output...)

hasufell commented 1 year ago

I'm not sure I understand the proposed design. What exactly should HLS do here?

merijn commented 1 year ago

I'm not sure what's unclear: If the number of errors that are not typed holes is >0, then don't report "errors" from typed holes. If number of errors from typed holes is 0, then report "errors" from typed holes.

hasufell commented 1 year ago

Isn't that rather a client thing?

Reorganizing or hiding errors doesn't seem like the job of the LSP server to me.

michaelpj commented 1 year ago

I also don't think this is a HLS thing. We report what GHC says. The complaint here is equally valid for any other consumer of GHC, even just compiling on the command line. You might also want to not see the errors for holes in those scenarios If it was fixed in GHC with a flag, then you could set the flag in your project build and HLS would do the right thing.

So I think this is a GHC issue.

merijn commented 1 year ago

The distinction is that the HLS has the tools to detect the difference between typed holes and other warnings properly, any client is limited to doing lousy textual/regex matching on the error text and kinda hoping GHC doesn't change the output.

Basically, the problem here is that HLS provides no override mechanism to use different flags from the cabal file. I want to see typed holes errors when I run cabal build, I do not want them in my editor. In ghcide, etc. I manually overrode things to not be shown.

HLS (at least, when I opened the ticket) does not provide any method of doing so.

hasufell commented 1 year ago

Can plugins intercept the messages that HLS sends or would this have to be implemented in the core?

michaelpj commented 1 year ago

I also think that something like e.g. a field in hie.yaml that tells hie-bios to load a cradle with additional flags wouldn't be crazy.

hasufell commented 1 year ago

So my take on this issue would be:

  1. if this requires changes to HLS core, I'd reject as won'tfix, because it's too specific
  2. if this is implementable as a plugin, someone can write a PR
  3. if this can be implemented by passing along GHC flags, it's also fine (but then this ticket is status: blocked)