Typed holes always appear as errors, even when deferred

[georgefst]

Does anyone know why, even with -fdefer-typed-holes, holes are reported as errors rather than warnings?

I've been curious about this for a while, but it hasn't caused my any real issues until now, when it gets in the way of using the Eval plugin.

[georgefst]

Okay, actually, my mistake. It doesn't get in the way of evaluation, I just had a typo in the flag name.

In which case, the only issue is seemingly the minor annoyance that these appear in red rather than yellow...

[lukel97]

The warnings appear in red?

[georgefst]

That is to say, in VScode for example, warnings from -Wtyped-holes appear as errors rather than warnings, which is inconsistent with GHC.

I'm not sure if there's really a practical distinction other than the colour and the little badge.

[michaelpj]

Does this still happen?

[georgefst]

I've learnt to live with it, but yes.

I think I looked in to it at some point, and the problem is that HLS always defers holes. And then explicitly decides to label them errors, so as not to confuse users who haven't set -fdefer-typed-holes.

I'd expect any errors (as opposed to warnings) in the editor to indicate that my code won't run.

[michaelpj]

Here's the problematic logic:

• Unconditionally setting deferring flags: https://github.com/haskell/haskell-language-server/blob/master/ghcide/src/Development/IDE/Core/Compile.hs#L597
• Unconditionally un-deferring things: https://github.com/haskell/haskell-language-server/blob/master/ghcide/src/Development/IDE/Core/Compile.hs#L617

We shouldn't un-defer things if the user specified to defer them.