October 2017 - ghc-tickets

[GHC] #12150: Compile time performance degradation on code that uses undefined/error with CallStacks
by GHC 01 Nov '17

01 Nov '17

#12150: Compile time performance degradation on code that uses undefined/error with CallStacks -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- GHC 8 has a lot of trouble compiling the following program: {{{#!hs module Serialize where data Result a = Success a | Error String {- 80 guards ghc-7.10.3 -O : 0.3s ghc-8.0.1 -O : 1.8s -} instance Functor Result where {-# INLINE fmap #-} fmap | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f where bool = undefined f = undefined }}} Here are some timing results, depending on the number of `| bool = f` clauses: {{{ * ghc-8.0.1 N clauses : time (s) 10 : 0.61 20 : 0.78 40 : 1.03 80 : 1.64 160 : 2.83 320 : 5.16 640 : 10.37 1280 : 21.16 * ghc-7.10.3 N clauses : time (s) 10 : 0.33 20 : 0.29 40 : 0.34 80 : 0.30 160 : 0.32 320 : 0.35 640 : 0.48 1280 : 0.80 }}} I think this compile time difference is caused by the `CallStack` changes introduced in GHC 8.0. When I use a version of `undefined` that doesn't have a CallStack, there is no difference in compile time when using GHC 7.10 or GHC 8.0. This is my implementation of `undefined` without `CallStack`: {{{ import GHC.Exception (errorCallException) import GHC.Prim (raise#) import Prelude (Char) error :: [Char] -> a error s = raise# (errorCallException s) undefined :: a undefined = error "undefined without callstack" }}} This is the quick and dirty Python script I used to generate those timing results (ghc version is hardcoded): {{{#!py import os import tempfile import time import subprocess def src(n): return ''' module Test where data Result a = Success a | Error String instance Functor Result where {{-# INLINE fmap #-}} fmap {0} where bool = undefined f = undefined '''.format('\n | bool = f' * n) tempfile = tempfile.mktemp('.hs') print('tempfile = {0}'.format(tempfile)) print('N clauses : time (s)') for i in range(8): n = 10 * 2 ** i with open(tempfile, 'w') as f: f.write(src(n)) f.flush() t0 = time.time() subprocess.call(['ghc-8.0.1', '-v0', '-O', tempfile]) t1 = time.time() print(str(n).ljust(10) + ': %.2f' % (t1 - t0)) os.remove(tempfile) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12150> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #11787: Infer HasCallStack where possible
by GHC 01 Nov '17

01 Nov '17

#11787: Infer HasCallStack where possible -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Consider {{{ Prelude> :t error error :: GHC.Stack.Types.HasCallStack => [Char] -> a Prelude> :t (\x -> error x) (\x -> error x) :: (?callStack::GHC.Stack.Types.CallStack) => [Char] -> a }}} We would prefer to get the same type for the latter as the former. Moreover, when we execute on #11376 (comment 25), `:t error` will show the more complicated type too. My suggestion: during generalisation, when we see `?callStack::CallStack`, use the built-in type synonym `HasCallStack`. Note that this should only happen if the name used for the implicit parameter is actually `?callstack`. Eric would you like to consider this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11787> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11573: CallStacks show up unexpectedly in type of local binding in GHCi
by GHC 01 Nov '17

01 Nov '17

#11573: CallStacks show up unexpectedly in type of local binding in GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (Type checker) | 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: -------------------------------------+------------------------------------- It was noticed (in a thread on ghc-devs) that introducing a CallStack- carrying term into the RHS of a let binding in GHCi produces a type which itself carries a callstack. I could be wrong but as far as I know this is a bug: the solver should never introduce a constraint that the user didn't write; it should merely provide an empty callstack in the event that a callstack constraint can't be solved. {{{ Prelude> let myList = [1, 2, 3 :: Integer] Prelude> let myList' = myList ++ undefined Prelude> :t myList myList :: [Integer] Prelude> :t myList' myList' :: (?callStack::GHC.Stack.Types.CallStack) => [Integer] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11573> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11298: Implicit call stack empty in instance declarations
by GHC 01 Nov '17

01 Nov '17

#11298: Implicit call stack empty in instance declarations -------------------------------------+------------------------------------- Reporter: pikajude | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | 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: -------------------------------------+------------------------------------- Given the following code: {{{#!hs {-# LANGUAGE ImplicitParams #-} import GHC.Stack class Foo a where foo :: a -> String main = putStrLn $ foo () }}} In GHC 7.11.20151216, the following instances result in no output: {{{#!hs instance Foo () where foo () = prettyCallStack ?loc }}} {{{#!hs fooHelper = prettyCallStack ?loc instance Foo () where foo () = fooHelper }}} Though this one does: {{{#!hs fooHelper () = prettyCallStack ?loc instance Foo () where foo = fooHelper }}} The aforementioned instances all yield output with GHC 7.10.3 (after replacing `prettyCallStack` with `showCallStack`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11298> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14218: GHC.Stack.HasCallStack not compatible with ConstraintKinds
by GHC 31 Oct '17

31 Oct '17

#14218: GHC.Stack.HasCallStack not compatible with ConstraintKinds -------------------------------------+------------------------------------- Reporter: ntc2 | 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: -------------------------------------+------------------------------------- The programs `Good` and `Bad` are the same, except that `Bad` uses a constraint synonym including `GHC.Stack.HasCallStack` whereas `Good` inlines the constraints. I expect them to produce the same output, but they don't: {{{ $ ./Good ["callStack","f"] $ ./Bad ["f"] }}} Here is the source for `Good.hs`: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} -- For nullary 'Trivial' class module Main where import qualified GHC.Stack as Ghc class Trivial where instance Trivial where -- | Print the functions on the call stack. callStack :: (Ghc.HasCallStack, Trivial) => IO () callStack = print $ map fst (Ghc.getCallStack Ghc.callStack) f :: (Ghc.HasCallStack, Trivial) => IO () f = callStack main :: IO () main = f -- Should print @["callStack", "f"]@. }}} Here is the source for `Bad.hs`: {{{#!hs {-# LANGUAGE ConstraintKinds #-} -- For 'C' {-# LANGUAGE MultiParamTypeClasses #-} -- For nullary 'Trivial' class module Main where import qualified GHC.Stack as Ghc class Trivial where instance Trivial where type C = (Ghc.HasCallStack, Trivial) -- | Print the functions on the call stack. callStack :: C => IO () callStack = print $ map fst (Ghc.getCallStack Ghc.callStack) f :: C => IO () f = callStack main :: IO () main = f -- Should print @["callStack", "f"]@. }}} Tested compiled and interpreted with GHC 8.2.1 and 8.0.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14218> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #13372: Attach CallStack to IOError, add CallStack constraints to relevant functions in base
by GHC 31 Oct '17

31 Oct '17

#13372: Attach CallStack to IOError, add CallStack constraints to relevant functions in base -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.1 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: -------------------------------------+------------------------------------- In #12096 it is requested that we add CallStack to SomeException. This is a more conservative request for adding CallStack to IOError only. IOError is already an abstract data type, so it is a simple matter to augment it with space for a CallStack. The main design flex point is whether or not a `CallStack` should be associated with an IOError when it is constructed, or when it is thrown. There are pros and cons to both: 1. If it is associated at construction time, the call stack will reflect when the IOError was constructed, not when it was thrown. This could be arbitrarily far away from the actual throw site. I've been mostly using CallStack for monadic code, and so my primary concern is with where in the monadic code the exception was thrown, so this info isn't really what I want. 2. If it is associated at throw time, there are a few other problems. First, if someone uses throwIO rather than ioError, we won't actually associate a CallStack with the value. Second, if a user is rethrowing an exception, they may accidentally overwrite the old stack trace; but it was the original one that I wanted. For now, I suggest going with (1). Here is the proposal: * Add `ioeGetCallStack` and `ioeSetCallStack`, for setting and getting the `CallStack` recorded in `IOError` * `userError` and `mkIOError` gain a `HasCallStack` constraint. We have a choice for `annotateIOError`, but my suggestion is to NOT annotate it. * Let's annotate all functions that (transitively) may raise an IOError in base with `HasCallStack`. The primary benefit is now if I have a "file not found" exception or similar, I automatically get a stack trace saying exactly what code was run where the file was not found. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13372> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

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

31 Oct '17

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: (none) 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => highest * milestone: => 8.4.1 Comment: I'll try to reproduce this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14406: Core Lint error when compiling ghc with -g3
by GHC 31 Oct '17

31 Oct '17

#14406: Core Lint error when compiling ghc with -g3 -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Building ghc with the following build.mk: {{{ BuildFlavour = validate ifneq "$(BuildFlavour)" "" include mk/flavours/$(BuildFlavour).mk endif GhcLibHcOpts += -g3 GhcRtsHcOpts += -g3 GhcStage2Opts += -g3 }}} gives {{{ *** Core Lint errors : in result of Simplifier *** <no location info>: warning: [RHS of str_sjjS :: Addr#] The type of this binder is unlifted: str_sjjS Binder's type: Addr# *** Offending Program *** ... str_sjjS :: Addr# [LclId, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}] str_sjjS = src<libraries/base/Data/Data.hs:1099:38-41> ":%"# ... libraries/base/ghc.mk:4: recipe for target 'libraries/base/dist- install/build/Data/Data.o' failed }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14406> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14386: GHC doesn't allow Coercion between partly-saturated type constructors
by GHC 31 Oct '17

31 Oct '17

#14386: GHC doesn't allow Coercion between partly-saturated type constructors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: roles | 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 define an "opposite category" `newtype Op cat a b = Op (cat b a)` then representationally it forms an involution: applying `Op` twice gives the same representation as not applying it at all {{{ $ ... -ignore-dot-ghci GHCi, version 8.3.20170920: http://www.haskell.org/ghc/ :? for help Prelude> import Data.Coerce Prelude Data.Coerce> import Data.Type.Coercion Prelude Data.Coerce Data.Type.Coercion> newtype Op cat a b = Op (cat b a) Prelude Data.Coerce Data.Type.Coercion> :t coerce :: Op (Op cat) a b -> cat a b coerce :: Op (Op cat) a b -> cat a b :: Op (Op cat) a b -> cat a b Prelude Data.Coerce Data.Type.Coercion> :t Coercion :: Coercion (Op (Op cat) a b) (cat a b) Coercion :: Coercion (Op (Op cat) a b) (cat a b) :: Coercion (Op (Op cat) a b) (cat a b) }}} But these don't work: {{{ Prelude Data.Coerce Data.Type.Coercion> :t Coercion :: Coercion (Op (Op cat) a) (cat a) <interactive>:1:1: error: • Couldn't match representation of type ‘Op (Op cat1) a1’ with that of ‘cat1 a1’ arising from a use of ‘Coercion’ • In the expression: Coercion :: Coercion (Op (Op cat) a) (cat a) Prelude Data.Coerce Data.Type.Coercion> :t Coercion :: Coercion (Op (Op cat) cat <interactive>:1:38: error: parse error (possibly incorrect indentation or mismatched brackets) Prelude Data.Coerce Data.Type.Coercion> :t Coercion :: Coercion (Op (Op cat)) cat <interactive>:1:1: error: • Couldn't match representation of type ‘cat1’ with that of ‘Op (Op cat1)’ arising from a use of ‘Coercion’ ‘cat1’ is a rigid type variable bound by an expression type signature: forall (cat1 :: * -> * -> *). Coercion (Op (Op cat1)) cat1 at <interactive>:1:13-38 • In the expression: Coercion :: Coercion (Op (Op cat)) cat }}} I'm wondering if this is intentional -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14386> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12143: ApplicativeDo Fails to Desugar 'return True'
by GHC 31 Oct '17

31 Oct '17

#12143: ApplicativeDo Fails to Desugar 'return True' -------------------------------------+------------------------------------- Reporter: MichaelBurge | 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: -------------------------------------+------------------------------------- If I bring in a spurious parameter, ApplicativeDo correctly infers Functor. {{{ Prelude> :t \m -> do { x <- m; return True; } \m -> do { x <- m; return True; } :: Functor f => f t -> f Bool Prelude> :t \m -> do { m; return True; } \m -> do { m; return True; } :: Monad m => m a -> m Bool }}} However, without the spurious parameter, ApplicativeDo assumes monad. {{{ Prelude> :t do { return True; } do { return True; } :: Monad m => m Bool }}} The first block in particular shows two examples that seem inconsistent when placed next to each other. It seems like if 'x' is unused, then 'x <- m' and 'm' should be equivalent. I would expect all of these to desugar to Functor or Applicative. And maybe 'return True' should be Monad, but 'do { return True; }' should be Applicative? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12143> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8