November 2017 - ghc-tickets

[GHC] #14410: Windows 10 freeze caused by infinite recursion in WinGHCi
by GHC 08 Nov '17

08 Nov '17

#14410: Windows 10 freeze caused by infinite recursion in WinGHCi -------------------------------------+------------------------------------- Reporter: WinKlim | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Keywords: freeze | Operating System: Windows infinite recursion | Architecture: x86_64 | Type of failure: Other (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Got Windows freeze after I typed this in WinGHCi : {{{ Prelude> fib2 a b n = fib2 b (a+b) (n-1) Prelude> fib2 3 3 1 }}} With option +RTS -M1000m I didn't get the Windows freeze but the termination of the calculation didn't work in WinGHCi . Operating system : Windows 10 64 Bit . -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14410> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14395: Redefining pattern synonym in GHCi triggers "‘p’ is untouchable" error
by GHC 08 Nov '17

08 Nov '17

#14395: Redefining pattern synonym in GHCi triggers "‘p’ is untouchable" error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Load this file into GHCi: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} module Bug where data Foo a where FooInt :: Foo Int pattern Bar :: () => (a ~ Int) => Foo a pattern Bar = FooInt }}} And attempt to redefine `Bar` as follows: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, 1 module loaded. λ> pattern Bar = Nothing <interactive>:1:15: error: • Couldn't match expected type ‘p’ with actual type ‘Maybe a0’ ‘p’ is untouchable inside the constraints: a ~ Int bound by a pattern with pattern synonym: Bar :: forall a. () => a ~ Int => Foo a, in an equation for ‘pattern’ at <interactive>:1:9-11 ‘p’ is a rigid type variable bound by the inferred type of pattern :: Foo a -> p at <interactive>:1:1-21 Possible fix: add a type signature for ‘pattern’ • In the expression: Nothing In an equation for ‘pattern’: pattern Bar = Nothing • Relevant bindings include pattern :: Foo a -> p (bound at <interactive>:1:1) }}} There are two issues here: 1. There are several places in the error message that refer to a `pattern` with no name! {{{ in an equation for ‘pattern’ }}} {{{ the inferred type of pattern :: Foo a -> p at <interactive>:1:1-21 }}} {{{ • Relevant bindings include pattern :: Foo a -> p (bound at <interactive>:1:1) }}} 2. Why is this error happening in the first place? The error message mentions the type `Foo a -> p`, but in `pattern Bar = Nothing`, there isn't anything that should touch `Foo`. Note that this bug does not occur if a slightly different (but ostensibly equivalent) type signature for `Bar` is given in the original source file: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} module Works where data Foo a where FooInt :: Foo Int pattern Bar :: Foo Int pattern Bar = FooInt }}} {{{ λ> pattern Bar = Nothing λ> :i Bar pattern Bar :: Foo Int }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14395> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14438: Using a (meaningless) generic currency sign (¤) instead of $ causes panicing
by GHC 08 Nov '17

08 Nov '17

#14438: Using a (meaningless) generic currency sign (¤) instead of $ causes panicing --------------------------------------+--------------------------------- Reporter: Izmaki | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 8.0.2 Keywords: ¤ | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- The following two lines of HS produces the reported error. It was actually a mistype and probably not that serious, but I was told to report it. The issue is combining the "generic currency" symbol ¤ with the Integral constraint (using e.g. Integer instead as the constraint does not produce the same error). {{{#!hs Prelude> let ones x = snd $ divMod x 10 Prelude> ones ¤ (5 :: Integral) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] ¤_a2l9 :: t_a2l8[tau:1] (CHoleCan: ¤) [W] ¤_a2lJ :: t_a2lI[tau:1] (CHoleCan: ¤)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14438> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14436: Teach TemplateHaskell to generate less eye-hurting names
by GHC 08 Nov '17

08 Nov '17

#14436: Teach TemplateHaskell to generate less eye-hurting names -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 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: -------------------------------------+------------------------------------- If you look at the Haddocks for, e.g., the `singletons` package, one sees dozens of signatures containing unsightly names containing long integers. For instance, in the equation list for `Data.Singletons.Prelude.Either.IsLeft` we have {{{ IsLeft (Left _z_6989586621679437436) = TrueSym0 IsLeft (Right _z_6989586621679437439) = FalseSym0 }}} For definitions with lots of variables things quickly become unreadable. These names appear this way because they are generated by TemplateHaskell's `newName` function. This name is ultimately converted to a GHC `System` name by `Convert.thRdrName`. Such `Name`s are then pretty- printed including their uniques (see `Name.pprSystem`). I'm not sure I see the rationale for this. Surely if the names are tidied properly (e.g. using `TyConRep.tidyType`) there should be no need for the unique suffix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14436> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14435: GHC 8.2.1 regression: -ddump-tc-trace hangs forever
by GHC 07 Nov '17

07 Nov '17

#14435: GHC 8.2.1 regression: -ddump-tc-trace hangs forever -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Thanks to Christiaan Baaij for noticing this. Take this program: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Data.Type.Equality import GHC.TypeLits type family Replicate (n :: Nat) (x :: a) :: [a] where Replicate 0 _ = '[] Replicate n x = x : Replicate (n - 1) x replicateSucc :: (Replicate (k + 1) x) :~: (x : Replicate k x) replicateSucc = Refl }}} Note that this program does not typecheck (nor should it). In GHC 8.0.2 and 8.2.1, if you compile this with no tracing flags, it'll give the error: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:16:17: error: • Couldn't match type ‘Replicate (k + 1) x’ with ‘x : Replicate k x’ Expected type: Replicate (k + 1) x :~: (x : Replicate k x) Actual type: (x : Replicate k x) :~: (x : Replicate k x) • In the expression: Refl In an equation for ‘replicateSucc’: replicateSucc = Refl • Relevant bindings include replicateSucc :: Replicate (k + 1) x :~: (x : Replicate k x) (bound at Bug.hs:16:1) | 16 | replicateSucc = Refl | ^^^^ }}} Things become interesting when you compile this program with `-ddump-tc- trace`. In GHC 8.0.2, it'll trace some extra output and eventually reach the same error as above. In 8.2.1, however, the tracing hangs, causing compilation to never terminate! Here is the output right before it hangs: {{{ lk1 : tc_infer_args (invis) @a_11 tc_infer_args (vis) [anon] a_11 x_a1Dt lk1 x_a1Dt u_tys tclvl 1 k0_a1GD[tau:1] ~ a0_a1GF[tau:1] arising from a type equality k0_a1GD[tau:1] ~ a0_a1GF[tau:1] found filled tyvar k_a1GD[tau:1] :-> a0_a1GE[tau:1] u_tys tclvl 1 * ~ * arising from a kind equality arising from a0_a1GE[tau:1] ~ a0_a1GF[tau:1] u_tys tclvl 1 'GHC.Types.LiftedRep ~ 'GHC.Types.LiftedRep arising from a kind equality arising from a0_a1GE[tau:1] ~ a0_a1GF[tau:1] u_tys yields no coercion u_tys yields no coercion writeMetaTyVar a_a1GE[tau:1] :: * := a0_a1GF[tau:1] u_tys yields no coercion checkExpectedKind k0_a1GD[tau:1] a0_a1GF[tau:1] <a0_a1GF[tau:1]>_N tc_infer_args (vis) [anon] [a_11] Replicate (n_a1Ds - 1) x_a1Dt lk1 Replicate instantiating tybinders: @a_a1Dp := a0_a1GG[tau:1] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14435> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14415: Win32 SEH unwinding should print segfaults to stderr, not stdout
by GHC 07 Nov '17

07 Nov '17

#14415: Win32 SEH unwinding should print segfaults to stderr, not stdout -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.2.1 System | Keywords: | Operating System: Windows Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Looking at ghc/rts/win32/veh_excn.c we can see that on segfaults, e.g. null pointer access, GHC calls: {{{ fprintf(stdout, "Access violation in generated code" }}} Given these are segfaults, it seems that stderr would be a more appropriate stream to use. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14415> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 07 Nov '17

07 Nov '17

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): Replying to [comment:15 bgamari]: > Well, I think simonpj's question was really "why is the same simplification not also being performed when we inline the unfolding?" Indeed this is a good question and will need some investigation. One explanation could be that `newTyConEtadRhs` is inlined at the callsite of `newTyConInstRhs` because the constructor of `tycon_a9Sq` is known; and after that substitution the logic in comment:9 no longer applies. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14424: lcm :: Word -> Word -> Word is not specialised
by GHC 07 Nov '17

07 Nov '17

#14424: lcm :: Word -> Word -> Word is not specialised -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- `GHC.Real` defines `gcd` with two specialised versions `gcdInt'` and `gcdWord'` and rules {{{ {-# RULES "gcd/Int->Int->Int" gcd = gcdInt' "gcd/Word->Word->Word" gcd = gcdWord' #-} }}} It also defines `lcm x y = abs ((x `quot` (gcd x y)) * y)`, but specialises it only for `Int`: {{{ {-# SPECIALISE lcm :: Int -> Int -> Int #-} }}} So `lcm :: Int -> Int -> Int` will be compiled to a nice and fast `gcdInt'`, but `lcm :: Word -> Word -> Word` will not benefit from the existence of `gcdWord'`. This leads to a huge performance gap, about 8x. Here is a test program: {{{ module Main where import Data.Time.Clock main :: IO () main = do t0 <- getCurrentTime print $ maximum $ [ lcm x y | x <- [1..1000 :: Int], y <- [1..1000 :: Int] ] t1 <- getCurrentTime putStrLn "lcm :: Int -> Int -> Int" print $ diffUTCTime t1 t0 t0 <- getCurrentTime print $ maximum $ [ lcm x y | x <- [1..1000 :: Word], y <- [1..1000 :: Word] ] t1 <- getCurrentTime putStrLn "lcm :: Word -> Word -> Word" print $ diffUTCTime t1 t0 t0 <- getCurrentTime print $ maximum $ [ lcmWord x y | x <- [1..1000 :: Word], y <- [1..1000 :: Word] ] t1 <- getCurrentTime putStrLn "lcmWord :: Word -> Word -> Word" print $ diffUTCTime t1 t0 -- Similar to GHC.Real.lcm, but specialized for Word lcmWord :: Word -> Word -> Word lcmWord _ 0 = 0 lcmWord 0 _ = 0 lcmWord x y = abs ((x `quot` (gcd x y)) * y) }}} On my PC the output is: {{{ 999000 lcm :: Int -> Int -> Int 0.086963s 999000 lcm :: Word -> Word -> Word 0.591168s 999000 lcmWord :: Word -> Word -> Word 0.077644s }}} My proposal is to add a SPECIALIZE pragma to `GHC.Real`: {{{ {-# SPECIALISE lcm :: Word -> Word -> Word #-} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14424> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 07 Nov '17

07 Nov '17

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > At the risk of stating the obvious, because the tick is around a `Case`, not a `Var`. Well, I think simonpj's question was really "why is the same simplification not also being performed when we inline the unfolding?" Indeed this is a good question and will need some investigation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14429: Remove constraint types from HsExtension, post TTG
by GHC 07 Nov '17

07 Nov '17

#14429: Remove constraint types from HsExtension, post TTG -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: task | 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: -------------------------------------+------------------------------------- Once Trees that Grow is landed on the hsSyn AST, remove the constraint types from `HsExtension.hs` Hopefully `DataId`, `HasSourceText`, `OutputableX` etc can all go. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14429> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2