July 2018 - ghc-tickets

[GHC] #15443: ghc panic when running GI.init on intero REPL
by GHC 19 Aug '18

19 Aug '18

#15443: ghc panic when running GI.init on intero REPL --------------------------------------+------------------------------- Reporter: esclerofilo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- I cloned the [https://github.com/haskell-gi/gi-gtk-examples] repo to learn to use gi-gtk, deleted all version numbers in the .cabal file to make it build with the latest stack resolver (lts-12.2) and then opened ButtonBox.hs in emacs (spacemacs) with intero, opened the intero repl (without actually loading the buffer into the repl*) and what happened follows: {{{ Starting: stack ghci --with-ghc ghci "--docker-run-args=--interactive=true --tty=false" --no-build --no-load gi-gtk-examples GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/vicente/Escritorio/gi-gtk-examples /.stack-work/intero/intero-scriptBbJ8Bq λ import qualified GI.Gtk as GI (main, init) λ GI.init Nothing ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): nameModule system $dShow_a8qH Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} the contents of {{{/home/vicente/Escritorio/gi-gtk-examples/.stack- work/intero/intero-scriptBbJ8Bq}}} are: {{{ :set prompt "" :set -fbyte-code :set -fdefer-type-errors :set -fdiagnostics-color=never :set prompt "\4 " }}} Note: It happens on a terminal ghci invocation too, given the same parameters and configuration. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15443> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9441: Merge identical top-level expressions following simplification when it is safe to do so
by GHC 18 Aug '18

18 Aug '18

#9441: Merge identical top-level expressions following simplification when it is safe to do so -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If I redefine {{{#!hs {-# INLINE reverse #-} reverse :: [a] -> [a] reverse xs = build $ \c n -> foldl (\a x -> x `c` a) n xs }}} and then write a couple test cases: {{{#!hs appRev xs ys = xs ++ reverse ys revAppRev xs ys = reverse xs ++ reverse ys }}} I end up getting some rather annoying code duplication (lots of stuff omitted from the following): {{{#!hs Rec { poly_go_r2v3 poly_go_r2v3 = \ @ a_a2nF ds_a2zc eta_Xl -> case ds_a2zc of _ { [] -> eta_Xl; : y_a2zh ys_a2zi -> poly_go_r2v3 ys_a2zi (: y_a2zh eta_Xl) } end Rec } reverse reverse = \ @ a_a2nF eta_B1 -> poly_go_r2v3 eta_B1 ([]) Rec { revAppRev2 revAppRev2 = \ @ a_a2y7 ds_a2zc eta_B1 -> case ds_a2zc of _ { [] -> eta_B1; : y_a2zh ys_a2zi -> revAppRev2 ys_a2zi (: y_a2zh eta_B1) } end Rec } Rec { revAppRev1 revAppRev1 = \ @ a_a2y7 ds_a2zc eta_B1 -> case ds_a2zc of _ { [] -> eta_B1; : y_a2zh ys_a2zi -> revAppRev1 ys_a2zi (: y_a2zh eta_B1) } end Rec } Rec { appRev1 appRev1 = \ @ a_a2xE ds_a2zc eta_B1 -> case ds_a2zc of _ { [] -> eta_B1; : y_a2zh ys_a2zi -> appRev1 ys_a2zi (: y_a2zh eta_B1) } end Rec } }}} The `reverse` function was inlined three times. In each case, there was no fusion, so `build` was inlined and the resulting copy of the `reverse` worker lifted to the top level. It would seem to me that once simplification is complete, it should be safe to merge all these copies into one. They are all `Rec {\ ... -> ...}` forms, so I don't think this has any potential to introduce undesirable sharing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9441> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #15050: ScopedTypeVariables could allow more programs
by GHC 18 Aug '18

18 Aug '18

#15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Consider {{{ data P a = P data T1 a where MkT1 :: forall a. P a -> T1 a MkT2 :: forall a. P a -> T1 (a,a) MkT3 :: forall a b. b ~ Int => P a -> P b -> T1 a MkT4 :: forall a b. P a -> P b -> T1 a MkT5 :: forall a b c. b ~ c => P a -> P b -> P c -> T1 a }}} I can write this function {{{ foo :: T1 (Int, Int) -> () foo (MkT1 (P::P (Int,Int))) = () foo (MkT2 (P::P x)) = (() :: x ~ Int => ()) foo (MkT3 P (P::P Int)) = () foo (MkT4 P (P::P b)) = () foo (MkT5 P (P::P b) (P::P b)) = () }}} but this these two equations fail {{{ foo (MkT1 (P::P (Int,x))) = (() :: x ~ Int => ()) foo (MkT1 (P::P x)) = (() :: x ~ (Int,Int) => ()) }}} I am especially surprised by the second one, given that the very similar equation with `MkT2` works. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15050> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #8944: Warn instead of stopping on misplaced Haddock comments
by GHC 17 Aug '18

17 Aug '18

#8944: Warn instead of stopping on misplaced Haddock comments -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Given a simple module like {{{ module H where data F = F () -- ^ Comment for first type argument () }}} and trying to run Haddock on it, we'll get back {{{ /tmp/H.hs:4:12: parse error on input ‘(’ }}} The error message is rather sub-par in this scenario. It'd be great if we could instead print a warning saying that a Haddock comment is unexpected in that position and then continue on parsing. Best case scenario would be a more informative message such as “Documenting each constructor argument is not supported” but that might be quite a bit harder. Filing on GHC Trac as it's the parser that needs changing I believe. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8944> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15453: Bug in opt_trans_rule in OptCoercion
by GHC 16 Aug '18

16 Aug '18

#15453: Bug in opt_trans_rule in OptCoercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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 ForAllCo case in the definition of opt_trans_rule in OptCoercion is not right: {{{#!hs push_trans tv1 eta1 r1 tv2 eta2 r2 = fireTransRule "EtaAllTy" co1 co2 $ mkForAllCo tv1 (opt_trans is eta1 eta2) (opt_trans is' r1 r2') where is' = is `extendInScopeSet` tv1 r2' = substCoWithUnchecked [tv2] [TyVarTy tv1] r2 -- ill-kinded! }}} Given {{{co1;co2}}}, where {{{#!hs co1 = \/ tv1 : eta1. r1 co2 = \/ tv2 : eta2. r2 }}} We would like optimize the transitivity coercion. I think what we want is {{{#!hs \/tv1 : (eta1;eta2). (r1; r2[tv2 |-> tv1 |> eta1]) }}} Namely it should be {{{#!hs r2' = substCoWithUnchecked [tv2] [mkCastTy (TyVarTy tv1) eta1] r2 }}} If there is any program that could hit the bug it would be better, as we can add it to test cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15453> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #15149: Identical distinct type family fields miscompiled
by GHC 16 Aug '18

16 Aug '18

#15149: Identical distinct type family fields miscompiled -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given the code: {{{#!hs -- An.hs {-# LANGUAGE TypeFamilies #-} module An where data family An c :: * -- AnInt.hs {-# LANGUAGE TypeFamilies #-} module AnInt where import An data instance An Int = AnInt {an :: Int} deriving Show -- AnDouble.hs {-# LANGUAGE TypeFamilies #-} module AnDouble where import An data instance An Double = AnDouble {an :: Double} deriving Show -- Main.hs {-# LANGUAGE DisambiguateRecordFields #-} module Main where import AnInt import AnDouble main = print (AnDouble{an=1}, AnInt{an=1}) }}} I would expect this code to work. In reality it fails at runtime with GHC 8.2.2: {{{ Main.hs:4:15-28: warning: [-Wmissing-fields] * Fields of `AnDouble' not initialised: an * In the expression: AnDouble {an = 1} In the first argument of `print', namely `(AnDouble {an = 1}, AnInt {an = 1})' In the expression: print (AnDouble {an = 1}, AnInt {an = 1}) | 6 | main = print (AnDouble{an=1}, AnInt{an=1}) | ^^^^^^^^^^^^^^ *** Exception: Main.hs:4:15-28: Missing field in record construction an }}} And fails at compile time in GHC 8.4.2: {{{ Main.hs:4:31-41: error: * Constructor `AnInt' does not have field `an' * In the expression: AnInt {an = 1} In the first argument of `print', namely `(AnDouble {an = 1}, AnInt {an = 1})' In the expression: print (AnDouble {an = 1}, AnInt {an = 1}) | 6 | main = print (AnDouble{an=1}, AnInt{an=1}) | ^^^^^^^^^^^ }}} This code was extracted from a real example, where this bug is pretty fatal, as I haven't been able to find any workarounds (without just avoiding clashing record fields). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15149> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12980: Unlifted class method rejected
by GHC 13 Aug '18

13 Aug '18

#12980: Unlifted class method rejected -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- If I say {{{#!hs class C a where meth :: Array# a }}} I get {{{ • Expecting a lifted type, but ‘Array# a’ is unlifted • In the type signature: meth :: Array# a In the class declaration for ‘C’ }}} This definition looks OK to me. I don't see why we can't have an unlifted member of a class. (As @oerjan points out in comment:25:ticket:12708, we can't have a ''levity-polymorphic'' class member, but this is solidly levity- monomorphic.) I'm happy to lift this restriction in ongoing work in this area, but I wanted to double-check before doing so. For the record, the same error occurs even when the class has more than one member, so it's not the no-unlifted-newtypes restriction. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12980> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14373: Introduce PTR-tagging for big constructor families
by GHC 11 Aug '18

11 Aug '18

#14373: Introduce PTR-tagging for big constructor families -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Currently only ''small'' constructor families come into the benefit of pointer tagging. In big fams, 1 is the tag that says "I am evaluated". I suggest to do best-effort pointer tagging on big families too by this scheme: Ptr-tag 1..6 for the first 6 constructors, 7 would signify "look into the info table and branch on that tag". In the info table the tags will then be 6..(familySize - 1). I have an implementation which I'll submit to fabricator soon. TODOs: update wiki pages. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14373> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9214: UNPACK support for sum types
by GHC 11 Aug '18

11 Aug '18

#9214: UNPACK support for sum types ------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently the pragma only supports single-constructor types. So in the following example it will simply be ignored: {{{ data A = A1 Char | A2 {-# UNPACK #-} !B data B = B1 Int | B2 Bool }}} However the problem seems to be easily solvable by denormalizing the type {{{A}}} to something like the following during unpacking: {{{ data A = A1 Char | A2_1 Int | -- from B1 A2_2 Bool -- from B2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9214> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12065: there is a way to override the .tix path with HPCTIXFILE
by GHC 11 Aug '18

11 Aug '18

#12065: there is a way to override the .tix path with HPCTIXFILE -------------------------------------+------------------------------------- Reporter: kostmo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Under the [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/hpc.html#id… "Caveats and Shortcomings of Haskell Program Coverage" section], it says: > There is no way to change the name of the .tix file generated, apart from renaming the binary. However, specifying `HPCTIXFILE` as an environment variable when running the executable program does change the output path of the `.tix` file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12065> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3