March 2018 - ghc-tickets

[GHC] #14238: `:kind` suppresses visible dependent quantifiers by default in GHCi 8.2.1
by GHC 07 Apr '18

07 Apr '18

#14238: `:kind` suppresses visible dependent quantifiers by default in GHCi 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Load this program into GHCi on 8.2.1 or later: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeInType #-} import Data.Kind data Foo (k :: Type) :: k -> Type where MkFoo :: Foo (k1 -> k2) f -> Foo k1 a -> Foo k2 (f a) }}} And ask it what the kind of `Foo` is: {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Ok, 1 module loaded. λ> :k Foo Foo :: k -> * }}} This is just plain wrong: the actual kind of `Foo` should be `forall k -> k -> *`. Normally, one can omit `forall`s from a kind signature, but this is a special case where we're using a //visible// forall. In other words, `forall k -> k -> *` is not the same as `k -> *`, as the former takes two arguments, whereas the latter takes one. A workaround is to force GHCi to come to its senses by explicitly enabling `-fprint-explicit-foralls`: {{{ λ> :set -fprint-explicit-foralls λ> :k Foo Foo :: forall k -> k -> * }}} This is actually a regression since GHC 8.0.2, since GHCi did the right thing by default then: {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Ok, modules loaded: Main. λ> :k Foo Foo :: forall k -> k -> Type }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14238> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14089: Segmentation fault/access violation using Yesod and Postgresql
by GHC 07 Apr '18

07 Apr '18

#14089: Segmentation fault/access violation using Yesod and Postgresql --------------------------------------+--------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- When trying to build a Yesod site with Postgresql I got the following: I tried to use PostgreSQL and got the following: website-0.0.0: configure (lib) Configuring website-0.0.0... website-0.0.0: build (lib) Preprocessing library website-0.0.0... [ 1 of 11] Compiling Settings ( src\Settings.hs, .stack- work\dist\ca59d0ab\build\Settings.o ) [ 2 of 11] Compiling Settings.StaticFiles ( src\Settings\StaticFiles.hs, .stack-work\dist\ca59d0ab\build\Settings\StaticFiles.o ) Segmentation fault/access violation in generated code -- While building package website-0.0.0 using: C:\sr\setup-exe-cache\x86_64-windows\Cabal- simple_Z6RU0evB_1.24.2.0_ghc-8.0.2.exe --builddir=.stack- work\dist\ca59d0ab build lib:website --ghc-options " -ddump-hi -ddump-to- file" Process exited with code: ExitFailure 1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14089> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11815: Data.List: Add a function to get consecutive elements (mapConsecutives)
by GHC 06 Apr '18

06 Apr '18

#11815: Data.List: Add a function to get consecutive elements (mapConsecutives) -------------------------------------+------------------------------------- Reporter: holmisen | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: | Version: libraries/base | 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: -------------------------------------+------------------------------------- A recurring pattern is to get a list of all consecutive elements of a list, for further processing. I propose adding the following function to `Data.List` for this: {{{ mapConsecutives :: (a -> a -> b) -> [a] -> [b] mapConsecutives _ [] = [] mapConsecutives f xs = zipWith f xs (tail xs) }}} Since it requires pattern matching, to separate the empty case, it is not practical to inline at each use site. Sidenote: A similar function `mapAdjacent` is available in the `utility- ht` library (with a partial implementation(!)) [1]. I realise that `Data.List` is often imported unqualified and hence additions may cause trouble. I would have raised this on the libraries mailing list first, but the guidelines for proposals pointed me here. [1] http://hackage.haskell.org/package/utility-ht-0.0.11/docs/Data-List- HT.html#v:mapAdjacent -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11815> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #14951: SpecContsr needs two runs when one should suffice
by GHC 06 Apr '18

06 Apr '18

#14951: SpecContsr needs two runs when one should suffice -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: SpecConstr | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14844 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a spin-off of #14844, which is a spin-off of #14068, but applies on its own. Consider this code: {{{ module T14844Example (topLvl) where topLvl large = (bar1, bar2, foo) where foo :: Integer -> (a -> b -> Bool) -> (a,b) -> Bool foo 0 _ _ = False foo s f t = l s' t where l 0 t = False l 1 t = case t of (x,y) -> f x y l n (x,y) = l (n-1) (x,y) s' = large s bar1 :: Integer -> (a -> b -> Bool) -> a -> b -> Bool bar1 s f x y = foo s f (x,y) bar2 :: Integer -> (a -> b -> Bool) -> a -> b -> Bool bar2 s f x y = foo (s + 1) f (x,y) }}} Status quo: `l` gets specialized, because of the two call patterns `s' t0` and `(s-1) (x,y)`, the second one is interesting *and* its second argument gets scrutinized (the `scu_occs` field reports `ScrutOcc` for `t`). But `foo` does not get specialized: It does have an interesting call pattern, but `scu_occs` reports `UnkOcc`, because `foo`’s parameters are just passed to `t`. But: When we decide to !SpecConstr `l`, we know that one of the calls to `l` is of the shape `s' t0`. This is a boring call, and we do not create a specialization for it. But we create a specialization for `l` using the the other call pattern. This means we know that it would be beneficial if `t0` were a constructor. So can we, at this point, decide to include `t0 ↦ ScrutOcc` in `scu_occs`? First experiments look good, so I am working on this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14951> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #12949: Pattern coverage mistake
by GHC 06 Apr '18

06 Apr '18

#12949: Pattern coverage mistake -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I disabled syntax highlighting below; the bugs highlighting single quotes made the code unreadable. {{{ {-# LANGUAGE DataKinds, TypeFamilies, GADTs, TypeOperators, ScopedTypeVariables, ConstraintKinds, StandaloneDeriving #-} {-# OPTIONS_GHC -Wall #-} import Data.Constraint import Data.Type.Bool -- Bool singletons data Boolly b where Falsey :: Boolly 'False Truey :: Boolly 'True deriving instance Show (Boolly b) class KnownBool b where knownBool :: Boolly b instance KnownBool 'False where knownBool = Falsey instance KnownBool 'True where knownBool = Truey -- OrRel a b r expresses all the usual implications inherent -- in the statement that r ~ (a || b). type OrRel (a :: Bool) (b :: Bool) (r :: Bool) :: Constraint = (r ~ (a || b), If r (If (Not a) (b ~ 'True) (() :: Constraint), If (Not b) (a ~ 'True) (() :: Constraint)) (a ~ 'False, b ~ 'False)) -- Given known Bools, their disjunction is also known abr :: forall a b r p1 p2 . (OrRel a b r, KnownBool a, KnownBool b) => p1 a -> p2 b -> Dict (KnownBool r) abr _ _ = case knownBool :: Boolly a of Truey -> Dict Falsey -> case knownBool :: Boolly b of Truey -> Dict -- Problematic match Falsey -> Dict }}} The trouble is that GHC warns that the problematic match is redundant, which it is not. If I remove it, GHC ''fails'' to warn that the patterns are incomplete, which they are. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12949> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1
by GHC 05 Apr '18

05 Apr '18

#14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I recently noticed that the performance of `doctest` in GHC 8.2.1 can be much, much worse than in previous versions of 8.0.2. So bad, in fact, that a project with 865 `doctest` examples takes about three hours to complete in 8.2.1, whereas it would only take 8 seconds in 8.0.2. To reproduce this issue in a fairly minimal way, you can use the following script to generate a file which simulates what `doctest` is doing: {{{#!hs -- GenExample.hs module Main where import Control.Monad import System.Environment import System.Exit import System.IO main :: IO () main = do args <- getArgs case args of n:_ -> genExamples (read n) _ -> do hPutStrLn stderr "usage: runghc GenExamples.hs <num-examples>" exitWith $ ExitFailure 1 genExamples :: Int -> IO () genExamples nExamples = do putStrLn ":l Foo" ireplicateA_ nExamples genExample genExample :: Int -> IO () genExample i = putStr $ unlines [ ":m *Foo" , "example : \"expr" ++ show i ++ "\"" , "let foo = it" , "\"marker\"" , "let it = foo" ] ireplicateA_ :: Applicative m => Int -> (Int -> m a) -> m () ireplicateA_ cnt0 f = loop cnt0 0 where loop cnt n | cnt <= 0 = pure () | otherwise = f n *> (loop (cnt - 1) $! (n + 1)) }}} You'll also need this file: {{{#!hs -- Foo.hs module Foo where example :: Char example = 'a' }}} First, use `GenExample` to generate a GHCi script: {{{ $ runghc GenExample.hs 500 > Example.script }}} Now you can run the script like so (using GHCi 8.0.2 as an example): {{{ $ /opt/ghc/8.0.2/bin/ghci -ghci-script Example.script Foo.hs }}} With GHCi 8.0.2, this takes about three seconds. But with GHCi 8.2.1, this takes about 35 seconds! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14052> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27

[GHC] #12938: Polykinded associated type family rejected on false pretenses
by GHC 04 Apr '18

04 Apr '18

#12938: Polykinded associated type family rejected on false pretenses -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: TypeInType | 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 {{{ class HasRep a where type Rep a :: TYPE r }}} I get {{{ • Kind variable ‘r’ is implicitly bound in datatype ‘Rep’, but does not appear as the kind of any of its type variables. Perhaps you meant to bind it (with TypeInType) explicitly somewhere? Type variables with inferred kinds: a • In the class declaration for ‘HasRep’ }}} This definition should be accepted, though, as `r` is just an invisible parameter to the associated type family. (I don't know how ''useful'' this is, but it's not bogus.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12938> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12742: Instantiation of invisible type family arguments is too eager
by GHC 04 Apr '18

04 Apr '18

#12742: Instantiation of invisible type family arguments is too eager -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- This module looks, to me, like it should be accepted: {{{ {-# LANGUAGE TypeInType, RankNTypes, TypeFamilies #-} module Bug where import Data.Kind type family F :: forall k2. (k1, k2) data T :: (forall k2. (Bool, k2)) -> Type type S = T F }}} But it's not. The problem is that `TcHsType.handle_tyfams` eagerly instantiates ''all'' invisible arguments to a type family at every occurrence. Instead, it should instantiate only those that are counted in the TF's arity -- that is, those "before the colon". Will fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12742> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14764: Make $! representation-polymorphic
by GHC 04 Apr '18

04 Apr '18

#14764: Make $! representation-polymorphic -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.2.2 Libraries | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4382 | Wiki Page: -------------------------------------+------------------------------------- Currently, {{{#!hs ($) :: forall r a (b :: TYPE r). (a -> b) -> a -> b }}} but {{{#!hs ($!) :: (a -> b) -> a -> b }}} It seems fairly obvious that we should generalize `($!)`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14764> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14795: Data type return kinds don't obey the forall-or-nothing rule
by GHC 04 Apr '18

04 Apr '18

#14795: Data type return kinds don't obey the forall-or-nothing rule -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Originally noticed [https://github.com/ghc-proposals/ghc- proposals/pull/103#issuecomment-364562974 here]. GHC accepts this: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} import Data.Kind data Foo :: forall a. a -> b -> Type where MkFoo :: a -> Foo a b }}} Despite the fact that `Foo`'s return kind is headed by an explicit `forall` which does not quantify `b`. The users' guide doesn't explicitly indicate that the `forall`-or-nothing rule should apply to data type return kinds, but goldfirere believes that not doing so is an [https://github.com/ghc-proposals/ghc- proposals/pull/103#issuecomment-364670215 inconsistent design], so I'm opening this ticket to track this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14795> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4