Excellent, Thanks!
@mpickering I uploaded your changes and added a very short commit message.
As I don't want to be the author of a patch I didn't write myself, I kindly ask you, to download branch T10617 from my Gitlab project and create a new MR with your ownership.
Again many thanks for your kind help.
Roland Senn (538327b0) at 07 Jan 20:58
RTTI: Substitute the [rk] skolems into kinds
... and 5 more commits
Works!! Many thanks!
@mpickering Thanks for your remark! I apologize for the weak and confusing commit message / MR description. Both are now updated.
When a breakpoint is reached then the GHCi debugger calls
compiler/GHC/Runtime/Heap/Inspect.hs:cvReconstructType
and tries to
get a monomorphic type from a possible polymorphic type.
In the function compiler/GHC/Runtime/Heap/Inspect.hs:applyRevSubst
it substitutes the new calculated types back into the type variables.
The service function compiler/GHC/Tc/Utils/TcType.hs:writeMetaTyVar
checks that this substitution of types does not change the kind.
If the kind changes a
panic like here
occurs.
The function cvReconstructType
first asks quantifyType
for all the type variables of
the polymorphic type. For the #10617 (closed) example these are:
[k1_IVD[rt], k_IVE[rt], k2_aCF, k3_aCD, a1_IVF[rt]]
.
Three of them (k1_IVD[rt], k_IVE[rt], a1_IVF[rt])
are type variables for run time values. They have a TcTyVar
constructor with a TcTvDetail
field containing
RuntimeUnk
(printed as [rt]
). Normally quantifyType
returns only such RuntimeUnk type variables.
During the kind check they have kinds like RuntimeRep
, Type
, Type > Type
etc.
I think, the two other type variables (k2_aCF, k3_aCD) are kind variables. They have
a type constructor of TyVar
. They ovbiously don't pass the kind check during a substitution.
Therefore the fix for issue #10617 (closed) is to remove them from processing.
To exclude only the kind variables we would need a function like isKindVar :: TyVar > Bool
.
I couldn't find such a function. Also I didn't find a simple criteria to write such a function.
I would prefer to exclude explicitely only kind variables and not all with a TyVar
type constructor. Do you have any suggestions ?
Roland Senn (6da32aca) at 07 Jan 15:47
RTTI: Use only type variables with TcTyVar constructors.
In Haskell code, a lot of values are defined with polymorphic types. During program execution, however, there are no polymorphic values, every value has a fixed monomorphic type. At a breakpoint, the GHCi debugger tries to calculate the monomorphic type from a polymorphic function definition in the source. To do this, it creates constraint equations from the type variables of runtime values and solves these equation with the normal GHC type inference engine.
To build these equations, select only type variables with TcTyVar
constructors as they contain the wanted RuntumeUnk type variables,
remove type/kind variables with TyVar
constructors, as they are not needed.
Roland Senn (0a86cafa) at 05 Jan 18:40
RTTI: Use only type variables with TcTyVar constructors.
... and 7 more commits
Roland Senn (f212cece) at 02 Jan 17:10
Add a sourcerepository stanza to rts/rts.cabal
... and 149 more commits
This issue has been fixed by !6971 (closed).
@clyring: The fix is currently in HEAD and will show up in GHC 9.4.1. There is a little inaccuracy in this argument: In a lot of cases GHCi can calculate the type of a value without evaluating it! Sorry for the confusion.
@bgamari: !7277 (closed) contains a regression test for this issue.
If we change in the example the type annotation for writeCount
to :: StateT Int IO ()
we get:
roland@goms:~/Projekte/ghctest/T14628$ ghci T14628
GHCi, version 9.0.1: https://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( T14628.hs, interpreted )
Ok, one module loaded.
ghci> :br 12 46
Breakpoint 0 activated at T14628.hs:12:4663
ghci> putArrayBytes stdout [['1'..'9'],['2'..'8'],['3'..'7']]
Stopped in Main.putArrayBytes.writeCount, T14628.hs:12:4663
_result :: StateT Int IO () = _
putLine :: [Char] > IO () = _
x :: [Char] = "123456789"
[T14628.hs:12:4663] ghci> :t runStateT _result 0
runStateT _result 0 :: IO ((), Int)
The type of runStateT _result 0
is IO ((), Int)
. Its value
is a tuple living in the IO monad. Hence to extract the Intvalue we
have to lift the snd
function into the IO monad with the <$>
operator.
Continuing the above session doesn't show any errors:
[T14628.hs:12:4663] ghci> snd <$> runStateT _result 0
Stopped in Main.putArrayBytes.writeCount, T14628.hs:12:4663
_result :: StateT Int IO () = _
putLine :: [Char] > IO () = _
x :: [Char] = "123456789"
... [T14628.hs:12:4663] ghci>
However, if we use the original type annotion of MonadIO m => StateT Int m ()
then the _result
value has the type StateT Int m ()
.
While typechecking the expression snd <$> runStateT _result 0
GHCi doesn't know that m
is a monad.
GHCi gives the following nasty error:
roland@goms:~/Projekte/ghctest/T14628$ ghci T14628
GHCi, version 9.0.1: https://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( T14628.hs, interpreted )
Ok, one module loaded.
ghci> :break 12 46
Breakpoint 0 activated at T14628.hs:12:4663
ghci> putArrayBytes stdout [['1'..'9'],['2'..'8'],['3'..'7']]
Stopped in Main.putArrayBytes.writeCount, T14628.hs:12:4663
_result :: StateT Int m () = _
putLine :: [Char] > IO () = _
x :: [Char] = "123456789"
[T14628.hs:12:4663] ghci> snd <$> runStateT _result 0
<interactive>:3:5: error:
• No instance for (Functor m) arising from a use of ‘<$>’
Cannot resolve unknown runtime type ‘m’
Use :print or :force to determine these types
Relevant bindings include it :: m Int (bound at <interactive>:3:1)
These potential instances exist:
instance Functor (Either a)  Defined in ‘Data.Either’
instance Functor IO  Defined in ‘GHC.Base’
instance [safe] Functor m => Functor (StateT s m)
 Defined in ‘Control.Monad.Trans.State.Lazy’
...plus six others
...plus 28 instances involving outofscope types
(use fprintpotentialinstances to see them all)
• In the expression: snd <$> runStateT _result 0
In an equation for ‘it’: it = snd <$> runStateT _result 0
The GHCi debugger should show the type of _result
as one of the following:
forall {m :: * > *}. MonadIO m => [Char] > StateT Int m ()
MonadIO m => StateT Int m ()
StateT Int IO ()
MR !2623 (closed) removed only the panic. It didn't really fix the issue of the user. Therfore I reopened!
Loading the following code in GHCi causes a panic.
Versions affected at least 8.2.2 and 8.0.2
module Main where
import System.IO
import Control.Monad.IO.Class
import Control.Monad.Trans.State
import Text.Printf
putArrayBytes :: Handle  ^ output file handle
> [String]  ^ bytestrings
> IO Int  ^ total number of bytes written
putArrayBytes outfile xs = do
let writeCount x = modify' (+ length x) >> liftIO (putLine x) :: MonadIO m => StateT Int m ()
execStateT (mapM_ writeCount xs) 0
where putLine = hPutStrLn outfile . (" "++) . concatMap (printf "0x%02X,")
{
ghci:
:break 12 46
:trace putArrayBytes stdout [['1'..'9'],['2'..'8'],['3'..'7']]
snd $ runStateT _result 0
}
main = undefined
Configuring GHCi with the following packages:
GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( C:\test\test.hs, interpreted )
Ok, one module loaded.
Loaded GHCi configuration from C:\Users\Andi\AppData\Local\Temp\ghci34988\ghciscript
*Main> :break 12 46
Breakpoint 0 activated at C:\test\test.hs:12:4663
*Main> :trace putArrayBytes stdout [['1'..'9'],['2'..'8'],['3'..'7']]
Stopped in Main.putArrayBytes.writeCount, C:\test\test.hs:12:4663
_result :: StateT Int m () = _
putLine :: [Char] > IO () = _
x :: [Char] = "123456789"
[C:\test\test.hs:12:4663] [C:\test\test.hs:12:4663] *Main> snd $ runStateT _result 0
<interactive>:3:7: error:<interactive>: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64unknownmingw32):
No skolem info:
m_I5Cm[rt]
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler\utils\Outputable.hs:1133:58 in ghc:Outputable
callStackDoc, called at compiler\utils\Outputable.hs:1137:37 in ghc:Outputable
pprPanic, called at compiler\typecheck\TcErrors.hs:2653:5 in ghc:TcErrors
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
[C:\test\test.hs:12:4663] [C:\test\test.hs:12:4663] *Main> :r
[1 of 1] Compiling Main ( C:\test\test.hs, interpreted )
Ok, one module loaded.
*Main> :break 12 46
Breakpoint 1 activated at C:\test\test.hs:12:4663
*Main> :trace putArrayBytes stdout [['1'..'9'],['2'..'8'],['3'..'7']]
Stopped in Main.putArrayBytes.writeCount, C:\test\test.hs:12:4663
_result :: StateT Int m () = _
putLine :: [Char] > IO () = _
x :: [Char] = "123456789"
[C:\test\test.hs:12:4663] [C:\test\test.hs:12:4663] *Main> snd $ runStateT _result 0
<interactive>:7:7: error:<interactive>: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64unknownmingw32):
No skolem info:
m_I5Nz[rt]
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler\utils\Outputable.hs:1133:58 in ghc:Outputable
callStackDoc, called at compiler\utils\Outputable.hs:1137:37 in ghc:Outputable
pprPanic, called at compiler\typecheck\TcErrors.hs:2653:5 in ghc:TcErrors
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
[C:\test\test.hs:12:4663] [C:\test\test.hs:12:4663] *Main>
Maybe related to #13393.
Trac field  Value 

Version  8.2.2 
Type  Bug 
TypeOfFailure  OtherFailure 
Priority  normal 
Resolution  Unresolved 
Component  GHCi 
Test case  
Differential revisions  
BlockedBy  
Related  
Blocking  
CC  
Operating system  
Architecture 
Thanks to @wz1000 for backporting !5478 (closed) in !7178 (merged) to 9.0.2. This backport fixes this issue for GHC 9.0.2
Roland Senn (14e53b1b) at 13 Dec 09:59
Backport !5478 to GHC9.2 to fix #19460
... and 135 more commits
To be precise: I say that this patch fixes #19460. The comment about improving memory is my interpretation of this comment.
As @rae points out, with the introduction of GHC2021
in GHC 9.2.1 it's necessary to change the used language extensions and the definition of AppTreeT
to:
{# LANGUAGE GADTs, StandaloneKindSignatures #}
type AppTreeT :: forall k. k > *
data AppTreeT a where
Con :: AppTreeT a
App :: AppTreeT a > AppTreeT b > AppTreeT (a b)
The :break
point must now be set on line 12.
@rae Many thanks for your kind explanation.
GHC2021
is a breaking change. Therefore I suggest to enhance the error message with a list of the
options the user can try to fix his program. One of them would be StandaloneKindSignatures
.CUSKs
, it's a legacy feature.GHC 9.2.1 is no longer able to compile the test program of ticket #10617.
Load the following program (T10617) into GHCi:
{# LANGUAGE GADTs , PolyKinds #}
data AppTreeT (a::k) where
Con :: AppTreeT a
App :: AppTreeT a > AppTreeT b > AppTreeT (a b)
tmt :: AppTreeT (Maybe Bool)
tmt = App (Con :: AppTreeT Maybe) Con
f :: AppTreeT a > Bool
f (App (c@Con) _) = const True c
f _ = False
This gives the following error:
roland@goms:~/Projekte/ghctest/T10617$ switchghc 9.2.1
The Glorious Glasgow Haskell Compilation System, version 9.2.1
roland@goms:~/Projekte/ghctest/T10617$ ghci T10617
GHCi, version 9.2.1: https://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( T10617.hs, interpreted )
T10617.hs:5:19: error:
• Expected kind ‘k’, but ‘a’ has kind ‘k > k’
• In the first argument of ‘AppTreeT’, namely ‘a’
In the type ‘AppTreeT a’
In the definition of data constructor ‘App’

5  App :: AppTreeT a > AppTreeT b > AppTreeT (a b)
 ^
Failed, no modules loaded.
The error is independent of GHCi. When I add a main
function
and call plain ghc
then I also see the error message.
As @rae explaines below this is due to the introduction of GHC2021
in GHC 9.2.1.
The error message should contain some hints, what changes the user could try to get a program that compiles.
In the above program, replace the first 2 lines with
{# LANGUAGE GADTs, StandaloneKindSignatures #}
type AppTreeT :: forall k. k > *
data AppTreeT a where
Optional: