#13393: GHC panic: No skolem info -------------------------------------+------------------------------------- Reporter: sheyll | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Perhaps this is fixed already? See #13297, #13135, #12844. Would it be possible to check? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13393#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13393: GHC panic: No skolem info -------------------------------------+------------------------------------- Reporter: sheyll | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): OK, here's something with no dependencies which triggers the same panic: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} module Mediabus ( ) where import Control.Monad.Trans.RWS.Strict (RWST) import Data.Functor.Identity (Identity) import Data.Kind (Type) import Data.Word (Word16) data Rate data Audio (sampleRate :: Rate) (channelLayout :: Type) (encoding :: Type) data EncodeResult = MkEncodeResult { encodeResultLeftOverInput :: !(Maybe [Word16]) } data EncodeFailure data AacEncErrorCode data Aac (aot :: AacCodec) data AacCodec newtype AacEncSt (rate :: Rate) channels (codec :: AacCodec) = MkAacEncSt { _leftOvers :: Maybe [Word16] } -- makeLenses ''AacEncSt type Iso s t a b = forall p f. (Functor f) => (a -> f b) -> s -> (f t) instance (Monad m, Monoid w) => MonadState s (RWST r w s m) where iso :: (s -> a) -> (b -> t) -> Iso s t a b iso sa bt x = fmap bt . x . sa {-# INLINE iso #-} leftOvers :: forall rate_a750 channels_a753 codec_a757 rate_aaYK channels_aaYL codec_aaYM. Iso (AacEncSt rate_a750 channels_a753 codec_a757) (AacEncSt rate_aaYK channels_aaYL codec_aaYM) (Maybe [Word16]) (Maybe [Word16]) leftOvers = (iso (\ (MkAacEncSt x_aaYN) -> x_aaYN)) MkAacEncSt {-# INLINE leftOvers #-} type ASetter s t a b = (a -> Identity b) -> s -> Identity t class Monad m => MonadState s m | m -> s where (.=) :: MonadState s m => ASetter s s a b -> b -> m () l .= b = undefined {-# INLINE (.=) #-} type AacEncT rate channels codec m a = RWST Int () (AacEncSt rate channels codec) m a encodeLinearToAac :: AacEncT rate channels codec IO (Either EncodeFailure (Maybe (Audio rate channels (Aac codec)))) encodeLinearToAac = do mapM putBackLeftOverInputAndReturnOutput undefined undefined where putBackLeftOverInputAndReturnOutput (MkEncodeResult x) = do leftOvers .= x undefined }}} This was actually introduced in GHC 8.0.2, it seems. On GHC 8.0.1, it gives this error: {{{ Bug.hs:63:3: error: • Ambiguous type variable ‘t0’ arising from a use of ‘mapM’ prevents the constraint ‘(Traversable t0)’ from being solved. Probable fix: use a type annotation to specify what ‘t0’ should be. These potential instances exist: instance Traversable (Either a) -- Defined in ‘Data.Traversable’ instance Traversable Identity -- Defined in ‘Data.Functor.Identity’ instance Traversable Maybe -- Defined in ‘Data.Traversable’ ...plus two others ...plus 24 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In a stmt of a 'do' block: mapM putBackLeftOverInputAndReturnOutput undefined In the expression: do { mapM putBackLeftOverInputAndReturnOutput undefined; undefined } In an equation for ‘encodeLinearToAac’: encodeLinearToAac = do { mapM putBackLeftOverInputAndReturnOutput undefined; undefined } where putBackLeftOverInputAndReturnOutput (MkEncodeResult x) = do { leftOvers .= x; .... } }}} But on GHC 8.0.2, it panics: {{{ Bug.hs:63:8: error:ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): No skolem info: k_a2RY[sk] }}} So does GHC HEAD: {{{ Bug.hs:63:8: error:ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170307 for x86_64-unknown-linux): No skolem info: k_a3pM[sk:3] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1191:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1195:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcErrors.hs:2627:5 in ghc:TcErrors }}} The presence of `PolyKinds` is crucial to triggering this bug. Without `PolyKinds`, you get the same error message on GHC 8.0.2 and HEAD as you would with 8.0.1. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13393#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13393: GHC panic: No skolem info -------------------------------------+------------------------------------- Reporter: sheyll | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ha! I have a fix validating for #13371, and it seems to fix this one too! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13393#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13393: GHC panic: No skolem info -------------------------------------+------------------------------------- Reporter: sheyll | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"7e96526ac2ef5987ecb03217d3d616b6281c1441/ghc" 7e96526/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7e96526ac2ef5987ecb03217d3d616b6281c1441" Fix TcSimplify.decideQuantification for kind variables TcSimplify.decideQuantification was doing the Wrong Thing when "growing" the type variables to quantify over. We were trying to do this on a tyvar set where we'd split off the dependent type varaibles; and we just got it wrong. A kind variable wasn't being generalised properly, with confusing knock on consequences. All this led to Trac #13371 and Trac #13393. This commit tidies it all up: * The type TcDepVars is renamed as CandidateQTvs; and splitDepVarsOfType to candidateQTyVarsOfType * The code in TcSimplify.decideQuantification is simpler. It no longer does the tricky "grow" stuff over TcDepVars. Instead it use ordinary VarSets (thereby eliminating the nasty growThetaTyVarsDSet) and uses that to filter the result of candidateQTyVarsOfType. * I documented that candidateQTyVarsOfType returns the type variables in a good order in which to quantify, and rewrote it to use an accumulator pattern, so that we would predicatably get left-to-right ordering. In doing all this I also made UniqDFM behave a little more nicely: * When inserting an element that is there already, keep the old tag, while still overwriting with the new value. * This means that when doing udfmToList we get back elements in the order they were originally inserted, rather than in reverse order. It's not a big deal, but in a subsequent commit I use it to improve the order of type variables in inferred types. All this led to a lot of error message wibbles: - changing the order of quantified variables - changing the order in which instances are listed in GHCi - changing the tidying of variables in typechecker erors There's a submodule update for 'array' because one of its tests has an error-message change. I may not have associated all of them with the correct commit. }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13393#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler