eduardsergeev / vscode-haskutil Goto Github PK

So this:

{-# LANGUAGE DataKinds                          #-}
{-# LANGUAGE DeriveGeneric                      #-}
{-# LANGUAGE DuplicateRecordFields              #-}
{-# LANGUAGE FlexibleContexts                   #-}
{-# LANGUAGE GeneralizedNewtypeDeriving         #-}
{-# LANGUAGE LambdaCase                         #-}
{-# LANGUAGE MultiParamTypeClasses              #-}
{-# LANGUAGE OverloadedStrings                  #-}
{-# LANGUAGE RecordWildCards                    #-}
{-# LANGUAGE StandaloneDeriving                 #-}
{-# LANGUAGE TypeApplications                   #-}
{-# LANGUAGE TypeOperators                      #-}

Should is converted into:

{-# LANGUAGE DataKinds                  #-}
{-# LANGUAGE DeriveGeneric              #-}
{-# LANGUAGE DuplicateRecordFields      #-}
{-# LANGUAGE FlexibleContexts           #-}
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# LANGUAGE LambdaCase                 #-}
{-# LANGUAGE MultiParamTypeClasses      #-}
{-# LANGUAGE OverloadedStrings          #-}
{-# LANGUAGE RecordWildCards            #-}
{-# LANGUAGE StandaloneDeriving         #-}
{-# LANGUAGE TypeApplications           #-}
{-# LANGUAGE TypeOperators              #-}

👋 Hi! Thanks for the great tool. I've been using it recently with the simple GHC extension in VSCode. I ran into a tiny little issue that I think comes from this extension, but please point me elsewhere if that's not the case.

When suggesting an import the aliased name can be the same as the module name. For example trying to use Say.sayShow correctly suggests importing Say, but unfortunately also suggests aliasing the import:

This isn't wrong, but it is a little surprising and unnecessary. Instead of suggesting import qualified Say as Say, it would be nice if haskutil suggested import qualified Say.

Example:
With the following warning:

The import of ‘NetworkTag’
from module ‘Cardano.Address’ is redundant

And the following import statement:

import           Cardano.Address (NetworkTag(..), bech32)

Applying quick fix leads to:

import           Cardano.Address (NetworkTag(..))

Steps to reproduce:

1. Put this in a file

   import           Data.Hashable (Hashable)
   import qualified Data.HashMap.Strict as HM

2. See that Haskutil complains that imports are unorganized.
3. Select 'Organize imports'. Code is not changed.
4. Save file. Haskutil still complains that imports are unorganized.

Tried on VSCode 1.44.1, Haskutil 0.8.0

Integration tests intermittently fail on CI with Error: Timeout of 30000ms exceeded message.
Not sure why, test might not be seeing expected number of Haskell diagnostic messages (required by tests?

An attempt to apply Quick Fix for the below code under GHC 9.6.5:

f0 :: (Num a, _) => a -> a
f0 x = x + x

fe :: _ => a -> a
fe x = x

leads to invalid Haskell code:

f0 :: (Num a, () :: Constraint) => a -> a
f0 x = x + x

fe :: () :: Constraint => a -> a
fe x = x

while in older GHC version the same QuickFix actions produces the correct code:

f0 :: (Num a) => a -> a
f0 x = x + x

fe :: a -> a
fe x = x

Currently when class or constructor is not in scope the only option offered is Add: "import Module.Name (ClassName)".
It should also propose to add import Module.Name (ClassName(..)) which should also be default/preferable option.

Since GHC 8.8 the error messages of constraint holes have range of the entire type signature rather than just the hole, which means filling the hole destroys the type signature:

fn :: _ => a -> a
--    ^^^^^^^^^^^ Error message range
-- Result: fn :: Num a
fn x = x + x

It makes some sense because the constraint wildcards are only allowed at the top level:

ghci> :t (undefined :: (_ => Int) -> Int)

<interactive>:1:16: error:
    Wildcard ‘_’ not allowed in a constraint
      except as the last top-level constraint of a type signature
        e.g  f :: (Eq a, _) => blah
      in an expression type signature

To solve this a crude parser might be needed to go through the rough structure [forall ... .] [(..., _) => | _ =>] ... at the beginning of the type signature to cover common cases.

GHC reports the inferred constraints in the form of a tuple, but such a tuple is not necessarily the best syntax to use, and nested constraint tuples require -XConstraintKinds. See examples:

f0 :: (Num a, _) => a -> a
-- Result: f0 :: (Num a, ()) => a -> a
-- Not idiomatic and needs -XConstraintKinds
-- Ideal: f0 :: (Num a) => a -> a or f0 :: Num a => a -> a
f0 x = x + x

f3 :: (Num a, _) => a -> Bool
-- Result: f3 :: (Num a, (Eq a, Read a, Show a)) => a -> Bool
-- Needs -XConstraintKinds
-- Ideal: f3 :: (Num a, Eq a, Read a, Show a) => a -> Bool
f3 x = read (show $ x + x) == x

fe :: _ => a -> a
-- Result: fe :: () => a -> a
-- Ideal: fe :: a -> a
fe x = x