Warnings emitted by the desugarer are not shown

[maralorn]

I sometimes have some enabled warnings which don‘t get displayed even if all other warnings are and there are no errors in the code. A cabal run on the same file shows the warning. My feeling is it depends on the category of the warning. I noticed the problem with following categories:

• all-missed-specialisations
• incomplete-patterns

There might be more. I’d like to know if this warnings work for anybody else.

[ndmitchell]

These warnings are generated by the desugarer. We only run as far as the type checker. We could go onwards, and have the code to do so, but it costs more CPU time. Should probably be added as a low priority rule and discard the output (to save memory).

[cocreature]

IIRC GHC shows these warnings even if you pass -fno-code. Probably worth looking at what code path triggers the warnings here.

[suhdonghwi]

So currently there is no workaround to make ghcide to emit those warnings?

[emlautarom1]

Does this mean that no warnings work? Currently using -Wall and -Wincomplete-record-updates on a project and I don't get any warnings at all.

[ndmitchell]

@emlautarom1 no, not by a very long way, 90%+ of warnings show up, just those about pattern matches. If you are seeing no warnings, its not because of this issue.

[emlautarom1]

@ndmitchell Then please, take a look at #934 since I'm getting no warnings when using -Wall and -Wincomplete-record-updates. This is the only reason I keep using ghcid instead of ghcide

[jneira]

@maralorn do you continue missing those warnings?

[maralorn]

@jneira On

haskell-language-server --version
haskell-language-server version: 0.4.0.0 (GHC: 8.8.4) (PATH: /nix/store/ri34qr8kzx4qwwg3yw4sj0skv738723v-haskell-language-server-0.4.0.0/bin/haskell-language-server)

yes.

{-# OPTIONS_GHC -Wall #-}
data A = A | B
f :: A ->  ()
f A = ()

This file shows a warning when compiled, but is clean in the editor.

[maralorn]

(Which is an especially important warning in my opinion. For example this ghc proposal wants to make incompleteness an error via an extension.)

[jneira]

@maralorn thanks for confirming that, i am not sure if this would be a feature request or a bug fix so both 😉

[Ericson2314]

@maralorn I am afraid -XNoIncomplete wouldn't allow emitting those warnings much earlier, because GHC's exaustive checker (massively) relies on already having types.

[ndmitchell]

It's not about types, its that these warnings are emitted during desugaring - we have the types available. If we could generate these warnings without doing a full desugar that would definitely be preferable. If not, desugaring is just a time/memory cost, with the benefit of getting these warnings.

[maralorn]

@Ericson2314 I didn‘t put any hopes in the proposal for fixing this issue. I just mentioned it to underline the importance of a fix. If anything the proposal would probably make this issue slightly worse since one could argue that a false negative on an error is worse than on a warning.

[wz1000]

One option is to desugar only on open/save, so that we don't take the performance hit on every keystroke.

[maralorn]

Would be possible to do the desugaring async? So that typechecker errors can be shown before the desugaring is finished?

[ndmitchell]

@maralorn - the architecture of ghcide is such that if you write it, its almost certainly going to be async. Doing it on open/save is one option, but to be fair, we haven't actually measured performance. That's worth doing before we try and decide if it needs optimising. I don't actually think it's all that hard to do. Approximately:

• Define a desugar warnings target, which runs the desugarer and collects warnings. This might already be in Ghcide somewhere, since DAML uses it.
• Make whatever asks for the type check values instead ask for the desugared warnings.
• Perhaps fiddle with flags to try and make desugaring do less work, if you can.

As a result, I'm marking it beginner suitable bug. I personally find the desugarer warnings mostly useless, which is why I never prioritised it way back when, but I appreciate I'm an outlier here!