servant-0.19 fails to compile on HEAD due to TypeErrors triggering more eagerly
servant-0.19
fails to build on GHC HEAD. Here is a minimized version of the issue:
{-# LANGUAGE AllowAmbiguousTypes #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE Haskell2010 #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE StandaloneKindSignatures #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeOperators #-}
{-# LANGUAGE UndecidableInstances #-}
module Bug where
import Data.Kind
import GHC.TypeLits
-- | No instance exists for @tycls (expr :> ...)@ because
-- @expr@ is not recognised.
type NoInstanceForSub (tycls :: k) (expr :: k') =
Text "There is no instance for " :<>: ShowType tycls
:<>: Text " (" :<>: ShowType expr :<>: Text " :> ...)"
-- | No instance exists for @expr@.
type NoInstanceFor (expr :: k) =
Text "There is no instance for " :<>: ShowType expr
-- | No instance exists for @tycls (expr :> ...)@ because @expr@ is not fully saturated.
type PartialApplication (tycls :: k) (expr :: k') =
NoInstanceForSub tycls expr
:$$: ShowType expr :<>: Text " expects " :<>: ShowType (Arity expr) :<>: Text " more arguments"
-- The arity of a combinator, i.e. the number of required arguments.
type Arity (ty :: k) = Arity' k
type Arity' :: k -> Nat
type family Arity' (ty :: k) :: Nat where
Arity' (_ -> ty) = 1 + Arity' ty
Arity' _ = 0
data (path :: k) :> (a :: *)
class HasLink endpoint where
instance TypeError (PartialApplication HasLink arr) => HasLink ((arr :: a -> b) :> sub)
This compiles with GHC 9.0.2 and 9.2.1, but fails to compile with HEAD:
$ ~/Software/ghc-9.3.20220216/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:40:10: error:
• There is no instance for HasLink (arr :> ...)
arr expects 1 + Arity' b more arguments
• In the ambiguity check for an instance declaration
In the instance declaration for ‘HasLink ((arr :: a -> b) :> sub)’
|
40 | instance TypeError (PartialApplication HasLink arr) => HasLink ((arr :: a -> b) :> sub)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I'm unclear if this change is intended behavior or not, but since I couldn't find any mention of TypeError
's behavior changing in the 9.4 release notes, I decided to open an issue.