August 2015 - ghc-tickets

[GHC] #10432: panic with kind polymorphism
by GHC 23 Dec '15

23 Dec '15

#10432: panic with kind polymorphism -------------------------------------+------------------------------------- Reporter: Ashley | Owner: Yakeley | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE ExistentialQuantification, PolyKinds, DataKinds, RankNTypes, GADTs, TypeOperators #-} module Bug where import Data.Type.Equality data WrappedType = forall a. WrapType a; matchReflK :: forall (a :: ka) (b :: kb) (r :: *). ('WrapType a :~: 'WrapType b) -> (('WrapType a ~ 'WrapType b) => r) -> r; matchReflK Refl r = r; }}} give this: {{{ Bug.hs:8:15: Couldn't match kind ‘ka’ with ‘kb’ ‘ka’ is untouchable inside the constraints ('WrapType a ~ 'WrapType b) bound by the type signature for matchReflK :: ('WrapType a ~ 'WrapType b) => r at Bug.hs:(8,15)-(9,74)ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): No skolem info: ka_aqv[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I actually think GHC should accept this (and furthermore infer `ka ~ kb`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10432> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9739: GHC 7.8 chokes on recursive classes
by GHC 23 Dec '15

23 Dec '15

#9739: GHC 7.8 chokes on recursive classes -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Type checking this makes GHC 7.8.3 loop: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} module Foo where class Class3 a => Class1 a where class Class2 t a where class2 :: (Class3 t) => a -> m class (Class1 t, Class2 t t) => Class3 t where }}} Does not happen in 7.6.3. I think it's something to do with the `Class3` constraint appearing in `class2`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9739> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10426: matchGroupArity panic with PatternSynonyms
by GHC 23 Dec '15

23 Dec '15

#10426: matchGroupArity panic with PatternSynonyms ---------------------------------------+--------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+--------------------------------- {{{#!hs {-# LANGUAGE PatternSynonyms, ViewPatterns, EmptyCase #-} pattern Id <- (id -> _) where }}} which gives: {{{#!hs % ghc -ignore-dot-ghci tmp.FbbzjZ48OO.hs [1 of 1] Compiling Main ( tmp.FbbzjZ48OO.hs, tmp.FbbzjZ48OO.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20150316 for i386-unknown-linux): matchGroupArity Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10426> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10039: Make Const (Control.Applicative) kind polymorphic in its second argument
by GHC 21 Dec '15

21 Dec '15

#10039: Make Const (Control.Applicative) kind polymorphic in its second argument -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: feature | Milestone: request | Version: 7.8.4 Priority: normal | Operating System: Unknown/Multiple Component: | Type of failure: None/Unknown libraries/base | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Is there any reason why `Const` isn't kind polymorphic? {{{#!hs newtype Const a (b :: k) = Const { getConst :: a } deriving (Generic, Generic1) }}} An example where I need it is for [[http://wiki.ocharles.org.uk/Name%20Binding%20in%20EDSLs|interpreting typed PHOAS]], the following fails to compile complaining that `The first argument of ‘PTerm’ should have kind ‘Ty -> *’, but ‘Const Char’ has kind ‘* -> *’`: {{{#!hs {-# LANGUAGE DataKinds, KindSignatures, GADTs, RankNTypes, PolyKinds #-} import Control.Applicative data Ty = TyBool | TyArr Ty Ty data PTerm :: (Ty -> *) -> Ty -> * where Var :: v t -> PTerm v t Tru :: PTerm v 'TyBool Fals :: PTerm v 'TyBool App :: PTerm v ('TyArr t1 t2) -> PTerm v t1 -> PTerm v t2 Abs :: (v t1 -> PTerm v t2) -> PTerm v ('TyArr t1 t2) newtype Term t = Term (forall v. PTerm v t) showT :: Term t -> String showT (Term pterm) = show' 'a' pterm where show' :: Char -> PTerm (Const Char) t -> String show' _ (Var (Const c)) = [c] show' _ Tru = "True" show' _ Fals = "False" show' s (App x y) = "(" ++ show' s x ++ ") " ++ show' s y show' s (Abs f) = [s] ++ ". " ++ show' (succ s) (f (Const s)) }}} but it compiles if one defines a bespoke form of `Const` with kind `* -> Ty -> *` (or the more general suggestion at the beginning of the ticket), I implemented all the related instances from `Control.Applicative` and the compiled without a hitch. Relevant discussion: a [[http://stackoverflow.com/questions/2023052/haskell-specifying-kind-in- data-declaration|question on StackOverflow]] that predates the `PolyKinds` extension effectively wants to define `type Const' (a :: * -> *) = Const Integer a` which would be possible if it were kind polymorphic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10039> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #10372: panic! compiling Y combinator with optimizations
by GHC 21 Dec '15

21 Dec '15

#10372: panic! compiling Y combinator with optimizations -------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: panic, | Operating System: Unknown/Multiple simplifier | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following causes GHC 7.6.3, 7.8.3 and 7.10.1 (at least) to panic when compiling with optimizations: {{{#!hs module Y (y) where newtype Rec a = Rec { out :: Rec a -> a} k x = out x x y f = (f . k) (Rec (f . k)) }}} {{{ /tmp ««« ghc -O y.hs -fforce-recomp [1 of 1] Compiling Y ( y.hs, y.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone a_sof To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 5282 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10372> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10814: Eliminate some ambiguity for IsString [a]
by GHC 21 Dec '15

21 Dec '15

#10814: Eliminate some ambiguity for IsString [a] -------------------------------------+------------------------------------- Reporter: dolio | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Core | Version: 7.10.2 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The libraries list resolved to make a modification to the `String` instance for `IsString` to resolve certain ambiguous cases. One example is: {{{#!hs "hello" ++ " world" }}} This case can be resolved by making the instance: {{{#!hs instance (a ~ Char) => IsString [a] where ... }}} rather than: {{{#!hs instance IsString [Char] where ... }}} as the former matches only based on the head being `[a]`, and subsequently determines `a ~ Char`, rather than only matching when other factors cause the head to be fully resolved to `[Char]`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10814> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10334: __ctzdi2/si2/__clzdi2/si2 unknown symbols in ghc-prim on non-shared libs platform
by GHC 19 Dec '15

19 Dec '15

#10334: __ctzdi2/si2/__clzdi2/si2 unknown symbols in ghc-prim on non-shared libs platform -------------------------------------+------------------------------------- Reporter: kgardas | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.11 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hello, ghc-prim is using GCC's {{{__builtin_ctz(ll)/clz(ll)}}} functions to implement functionality to count leading or trailing zeros in provided integer type variable. The problem with those GCC's builtins is that on platform which does not implement either of the operation in ISA, such function call can't be replaced by simple ISN, but needs to be replaced by the call to the libgcc library which then implements the missing operation in generic C. In ghc- prim you can already see a workaround for missing *ll functions on i386. The problem is that generic SPARC (v9) does not provide ISNs in its ISA to implement those builtins effectively so any call to builtins above is replaced by the call to the libgcc. The inserted functions calls are {{{__ctzsi2/__ctzdi2/__clzsi2/__clzdi2}}} in this case. Unfortunately this makes a lot of GHCi testcases (if not all!) failing with the error: {{{ ghc-stage2: /home/karel/src/obj-ghc-sparc-reg_ncg- head-2015-04-07-debug/libraries/ghc-prim/dist-install/build/HSghc- prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3.o: unknown symbol `__clzdi2' ghc-stage2: unable to load package `ghc-prim-0.4.0.0' }}} Please note, this happens only on platforms which does not support shared libs for GHC. On platforms with GHC shared libs support, ghc-prim is shared library which is correctly linked against the libgcc shared library and such error does not happen. (example Solaris/i386). Unfortunately we can't link ghc-prim*.o with libgcc -- it does effectively nothing so there are two solution for this issue IMHO: 1) on problematic platform implement hs_ctz*/hs_clz* functions in pure C without usage of GNU C builtin functions. or 2) enforce linking of shared libgcc with produced application binary. Such linking needs to be enforced with -shared-libgcc parameter passed to the GNU C in linking step and also by usage of either builtins in the application C code (not library code). My experimental code below shows that this is possible (tested on Solaris/SPARC). Please note that by default on static platform, the static version of libgcc is used and this does not help here. Also please note that usage of builtin in let say RTS library does not help either. I've tested RtsMain.c. The reason is the same like why it's not working in ghc-prim. We can't link *.o or *.a against shared libgcc. {{{ diff --git a/compiler/main/DriverPipeline.hs b/compiler/main/DriverPipeline.hs index c86667c..7c615d1 100644 --- a/compiler/main/DriverPipeline.hs +++ b/compiler/main/DriverPipeline.hs @@ -1651,6 +1651,7 @@ mkExtraObjToLinkIntoBinary dflags = do | gopt Opt_NoHsMain dflags = Outputable.empty | otherwise = vcat [ text "#include \"Rts.h\"", + text "#include <stdio.h>", text "extern StgClosure ZCMain_main_closure;", text "int main(int argc, char *argv[])", char '{', @@ -1662,6 +1663,10 @@ mkExtraObjToLinkIntoBinary dflags = do Just opts -> ptext (sLit " __conf.rts_opts= ") <> text (show opts) <> semi, text " __conf.rts_hs_main = rtsTrue;", + text " printf(\"ctz(argc): %d\\n\", __builtin_ctz(argc));", text " return hs_main(argc,argv,&ZCMain_main_closure,__conf);", char '}', char '\n' -- final newline, to keep gcc happy }}} of course this is just a proof of concept. For real code we would need some place to save the result of the called builtin to prevent GCC from removing the call as an unused value. I guess one added value in {{{__conf}}} just for this case should do the job here. I'm free to implement either of those two solutions or even completely different one, I just need to know your preference in this case. BTW: I'm ccing people from #9340 which looks really related to this issue. If you are not interested in this issue discussion, please un-cc yourself. Thanks! Karel PS: as this is IMHO general issue, I'm not setting SPARC/Solaris as Architecture/OS here... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10334> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10272: hsc2hs : directive let cannot be handled in cross-compilation mode
by GHC 19 Dec '15

19 Dec '15

#10272: hsc2hs : directive let cannot be handled in cross-compilation mode -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: hsc2hs | Version: 7.11 Keywords: cross- | Operating System: Unknown/Multiple compiling | Type of failure: Building GHC Architecture: | failed Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #10070 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Attempting to cross-compile from linux to windows (after an in-progress fix to #10070) and ran into: {{{ libraries/haskeline/System/Console/Haskeline/Backend/Win32.hsc:170 directive let cannot be handled in cross-compilation mode }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10272> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9394: Show data/type family instances with ghci's :info command
by GHC 18 Dec '15

18 Dec '15

#9394: Show data/type family instances with ghci's :info command -------------------------------------+------------------------------------- Reporter: s9gf4ult | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: ghci | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Current version of ghci (7.6.3) does not show data instances. For example, I have some Yesod application and I want to see all data constructors of (Route App) data family instance: {{{#!hs *Application> :info Route App class Eq (Route a) => yesod-routes-1.2.0.6:Yesod.Routes.Class.RenderRoute a where data family Route a1 ... -- Defined in `yesod-routes-1.2.0.6:Yesod.Routes.Class' instance Eq (Route App) -- Defined at Foundation.hs:48:1 instance Read (Route App) -- Defined at Foundation.hs:48:1 ................. }}} It just shows info about `Route`, then info about `App` separately. When I try this: {{{#!hs *Application> :info (Route App) <interactive>:1:2: parse error on input `Route' }}} I am getting parse error. I offer to use this syntax (with parentheses) to show info about instance of data/type family, namely, data constructors and such stuff, just like for ordinal `data`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9394> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10662: GHC warning shows technical summary of AST instead of the user's code
by GHC 17 Dec '15

17 Dec '15

#10662: GHC warning shows technical summary of AST instead of the user's code -------------------------------------+------------------------------------- Reporter: kolmodin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I got a warning for some code I wrote; {{{#!hs forkIO (....) }}} Naturally GHC warns me that I'm throwing away the result, and should write like this; {{{#!hs _ <- forkIO (...) }}} However, the warning is expressed in a somewhat confusing way, not sure this is intentional. {{{ examples/route_guide_client.hs:84:5: Warning: A do-notation statement discarded a result of type ‘ThreadId’ Suppress this warning by saying ‘_ <- ($) forkIO let AbsBinds [] [] {Exports: [go <= go <>] Exported types: go :: [L.ByteString] -> IO () [LclId, Str=DmdType] Binds: go acc = ...} in go []’ or by using the flag -fno-warn-unused-do-bind }}} I find it confusing that the warning mentions AbsBinds, exports and types. I'd expect a snippet of my code in the warning. However, doesn't look like this is a (recent) regression. The same happens GHC 7.8.4 and 7.10.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10662> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11