January 2018 - ghc-tickets

[GHC] #10789: Notify user when a kind mismatch holds up a type family reduction
by GHC 28 Jun '18

28 Jun '18

#10789: Notify user when a kind mismatch holds up a type family reduction -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider this contrived example: {{{ {-# LANGUAGE TypeFamilies, PolyKinds, UndecidableInstances #-} module Bug where import Data.Proxy type family F (a :: k) :: k type instance F a = G a type family G a type instance G a = a foo :: Proxy (F Maybe) -> Proxy Maybe foo = id }}} This (correctly) fails to compile. The error message is {{{ Bug.hs:14:7: Couldn't match type ‘F Maybe’ with ‘Maybe’ Expected type: Proxy (F Maybe) -> Proxy Maybe Actual type: Proxy Maybe -> Proxy Maybe In the expression: id In an equation for ‘foo’: foo = id Failed, modules loaded: none. }}} But this is peculiar, but it surely looks like `F` should be a type-level identity function! Of course, upon further inspection, we see that `F` is partial. It reduces only at kind `*`. This is quite hard to figure out, though, especially given that we're using the "default to `*`" behavior of open type families to arrange for this kind restriction. Thus, I propose: figure out when a type family reduction is held up due to a kind mismatch, and inform the user. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10789> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #12922: Kind classes compile with PolyKinds
by GHC 27 Jun '18

27 Jun '18

#12922: Kind classes compile with PolyKinds -------------------------------------+------------------------------------- Reporter: Tritlo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was asking around on #haskell to better understand the new language extension, -XTypeInType, and how it is different from -XPolyKinds. To study it, I was working with the following small example: {{{ {-# LANGUAGE TypeFamilies, GADTs, TypeOperators, DataKinds, PolyKinds #-} module Main where import Data.Kind (Type) -- Define a Type for the natural numbers, Zero and a successor data Nat = Z | S Nat class Addable k where type (a :: k) + (b :: k) :: k instance Addable Nat where type (Z + a) = a }}} (for more context, see https://gist.github.com/Tritlo/ce5510e80935ac398a33934ee47c7930) Since according to a responder on #haskell, the ability to have kind classes required TypeInType, and should not work with PolyKinds. As the documentation mentions that there could be leakage between PolyKinds and TypeInType and to report such leaks, I felt that I should report it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12922> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9383: GHCi parser doesn't properly handle -fobject-code
by GHC 27 Jun '18

27 Jun '18

#9383: GHCi parser doesn't properly handle -fobject-code -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- My complete Haskell source: module Foo where f x = x Shell: $ ghci Foo.hs -fobject-code GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. target ‘-fobject-code’ is not a module name or a source file Ok, modules loaded: Linker. Prelude Linker> Despite the wanring/error, GHCi *does* generate the object code. This error also prints when I *load* the compiled Foo object file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9383> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10965: GHC Panic on import with 'OPTIONS_GHC -fobject-code -O'
by GHC 27 Jun '18

27 Jun '18

#10965: GHC Panic on import with 'OPTIONS_GHC -fobject-code -O' --------------------------------------+--------------------------------- Reporter: Orome | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- I get {{{ > :l Test.hs [1 of 1] Compiling Main ( Test.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-apple-darwin): floatExpr tick break<11>() Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} with Test.hs: {{{ {-# OPTIONS_GHC -fobject-code -O #-} import Control.Exception (assert) import Data.Char (ord) f :: String -> String f s = assert (all (`elem` letters) s) $ (letters!!) <$> (ix <$> s) where ix ch = (ord ch - ord 'A') letters = ['A'..'Z'] }}} OSX 10.11, GHC 7.10.2; uad-core 64-bit haswell; Homebrew GHC -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10965> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13790: GHC doesn't reduce type family in kind signature unless its arm is twisted
by GHC 26 Jun '18

26 Jun '18

#13790: GHC doesn't reduce type family in kind signature unless its arm is twisted -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's some code (inspired by Richard's musings [https://github.com/goldfirere/singletons/issues/150#issuecomment-306088297 here]) which typechecks with GHC 8.2.1 or HEAD: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind data family Sing (a :: k) data SomeSing (k :: Type) where SomeSing :: Sing (a :: k) -> SomeSing k type family Promote k :: Type class (Promote (Demote k) ~ k) => SingKind (k :: Type) where type Demote k :: Type fromSing :: Sing (a :: k) -> Demote k toSing :: Demote k -> SomeSing k type family DemoteX (a :: k) :: Demote k type instance DemoteX (a :: Type) = Demote a type instance Promote Type = Type instance SingKind Type where type Demote Type = Type fromSing = error "fromSing Type" toSing = error "toSing Type" ----- data N = Z | S N data instance Sing (z :: N) where SZ :: Sing Z SS :: Sing n -> Sing (S n) type instance Promote N = N instance SingKind N where type Demote N = N fromSing SZ = Z fromSing (SS n) = S (fromSing n) toSing Z = SomeSing SZ toSing (S n) = case toSing n of SomeSing sn -> SomeSing (SS sn) }}} Things get more interesting if you try to add this type instance at the end of this file: {{{#!hs type instance DemoteX (n :: N) = n }}} Now GHC will complain: {{{ GHCi, version 8.2.0.20170522: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:49:34: error: • Expected kind ‘Demote N’, but ‘n’ has kind ‘N’ • In the type ‘n’ In the type instance declaration for ‘DemoteX’ | 49 | type instance DemoteX (n :: N) = n | ^ }}} That error message smells funny, since we do have a type family instance that says `Demote N = N`! In fact, if you use Template Haskell to split up the declarations manually: {{{#!hs ... instance SingKind N where type Demote N = N fromSing SZ = Z fromSing (SS n) = S (fromSing n) toSing Z = SomeSing SZ toSing (S n) = case toSing n of SomeSing sn -> SomeSing (SS sn) $(return []) type instance DemoteX (n :: N) = n }}} Then the file typechecks without issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13790> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12769: ghc: internal error: stg_ap_pp_ret
by GHC 22 Jun '18

22 Jun '18

#12769: ghc: internal error: stg_ap_pp_ret ----------------------------------------+---------------------------------- Reporter: kinnla | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- appeared when building a project on macOS Sierra: https://github.com/Potregon/while/blob See attached log file (told me to report the bug) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12769> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11958: Improved testing of cross-compiler
by GHC 21 Jun '18

21 Jun '18

#11958: Improved testing of cross-compiler -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: task | Status: new Priority: low | Milestone: 8.2.1 Component: Test Suite | Version: 7.10.3 Keywords: cross-compile | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It is already possible to build cross compiler eg from x86_64/linux to armhf/linux or arm64/linux, but there is currently no way to run the test suite. However, at least for the host and targets above, it should be possible to run the test executables under the Qemu user space emulation. I know this works, because in my own personal jenkins build instance, I test exactly this by doing (for x86_64/linux to amr64/linux cross): {{{ echo -e 'main :: IO ()\nmain = putStrLn "Hello World"\n' > hello-world.hs inplace/bin/ghc-stage1 hello-world.hs -o hello-world test $(file hello-world | grep -c 'ARM aarch64, version 1') -eq 1 ./hello-world }}} The linux machine I run the above test on is x86_64/linux but has Qemu and `binfmt` stuff set up so that it can run some foreign binaries. For instance, if GHC worked as a Linux to Windows cross-compiler the resulting windows binaries should work under Wine. To get this working, I suspect that just about all the required work is in the build system. Not sure if it might not be better to wait until the Shake based build system is in better shape. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11958> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14673: Unary Unboxed Tuple Type Constructor
by GHC 21 Jun '18

21 Jun '18

#14673: Unary Unboxed Tuple Type Constructor -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The type constructor for a unary unboxed tuple cannot be written in GHC haskell. Consider the following value which is wrapped in by a unary unboxed tuple: {{{ >>> :type (# 5# #) (# 5# #) :: (# Int# #) }}} Now consider the type constructor for unboxed 2-tuples: {{{ >>> :set -fprint-explicit-kinds >>> :set -fprint-explicit-foralls >>> :kind! (# , #) (# , #) :: forall (k0 :: RuntimeRep) (k1 :: RuntimeRep). TYPE k0 -> TYPE k1 -> TYPE ('TupleRep ((':) RuntimeRep k0 ((':) RuntimeRep k1 ('[] RuntimeRep)))) = (#,#) }}} Horrid looking, but undoubtedly correct. But how can we do this for a unary unboxed tuple? The naive approach gives us the nullary tuple instead: {{{ >>> :kind! (# #) (# #) :: TYPE ('TupleRep ('[] RuntimeRep)) = (# #) }}} I do actually have a real use-case for this that I can discuss more if needed. For the syntax, I really haven't the faintest idea what I would expect. Maybe something like: `(## ##)` or `(# @1 #)`, but those both seem pretty bad. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14673> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #14617: Join point test join001 doesn't seem to be properly automated
by GHC 21 Jun '18

21 Jun '18

#14617: Join point test join001 doesn't seem to be properly automated -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.2 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The test `join001` was presumably used for manual testing (poring over the Core by hand). Unfortunately, the test suite runs it in an utterly bland fashion that doesn't appear to check whether the join point transformation is working as intended. The other join point tests run in this fashion (`join005` and `join006`) include notes indicating that Core Lint will trip if the desired property doesn't hold; there is no such note here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14617> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14319: Stuck kind families can lead to lousy error messages
by GHC 21 Jun '18

21 Jun '18

#14319: Stuck kind families can lead to lousy error messages -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# language TypeFamilies, TypeInType, ScopedTypeVariables #-} module ArityError where import Data.Kind import GHC.TypeLits import Data.Proxy type family F (s :: Symbol) :: Type type family G (s :: Symbol) :: F s type instance G "Hi" = Maybe }}} This produces the error message {{{#!hs ArityError.hs:10:24: error: • Expecting one more argument to ‘Maybe’ Expected kind ‘F "Hi"’, but ‘Maybe’ has kind ‘* -> *’ • In the type ‘Maybe’ In the type instance declaration for ‘G’ | 10 | type instance G "Hi" = Maybe | ^^^^^ }}} This looks utterly bogus: `F "Hi"` is stuck, so we have no idea what arity it indicates. What I ''think'' is a term level version of this, {{{#!hs f :: forall (s :: Symbol). Proxy s -> F s f _ = Just }}} gives a much less confusing message: {{{ ArityError.hs:14:7: error: • Couldn't match expected type ‘F s’ with actual type ‘a0 -> Maybe a0’ The type variable ‘a0’ is ambiguous • In the expression: Just In an equation for ‘f’: f _ = Just • Relevant bindings include f :: Proxy s -> F s (bound at ArityError.hs:14:1) | 14 | f _ = Just | ^^^^ }}} The fix (I think) is to refrain from reporting arity errors when we don't know enough about the relevant arities. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14319> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5