May 2018 - ghc-tickets

Re: [GHC] #849: Offer control over branch prediction
by GHC 24 May '18

24 May '18

#849: Offer control over branch prediction -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: #14672 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * related: => #14672 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/849#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11968: Document AMP in the deviations from the standard
by GHC 24 May '18

24 May '18

#11968: Document AMP in the deviations from the standard -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- The manual includes a section describing deviations from the Haskell2010 standard [https://downloads.haskell.org/~ghc/master/users-guide/bugs.html here]. But this page makes no mention of `Applicative` being a superclass of `Monad`. We should fix this omission. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11968> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11319: ImpredicativeTypes cause trouble (affects deriving of Traversable)
by GHC 24 May '18

24 May '18

#11319: ImpredicativeTypes cause trouble (affects deriving of Traversable) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Keywords: | Operating System: Linux ImpredicativeTypes | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I don't have the latest version of GHC, trying to derive `Functor A` and `Foldable A` is fine but when I derive `Traversable A` in the attachment Error.hs: {{{#!hs {-# LANGUAGE DeriveFunctor, DeriveFoldable, DeriveTraversable, ImpredicativeTypes #-} import Data.Functor (Functor) import Data.Foldable (Foldable) import Data.Traversable (Traversable) data A a = A deriving (Functor, Foldable, Traversable) }}} GHC barks at me (verbose log attached): {{{#!hs /tmp/Error.hs:8:32: error: • Couldn't match type ‘forall a1. A a1’ with ‘A b’ Expected type: f (A b) Actual type: f (forall a. A a) • In the expression: pure A In an equation for ‘traverse’: traverse f A = pure A When typechecking the code for ‘traverse’ in a derived instance for ‘Traversable A’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘Traversable A’ • Relevant bindings include f :: a -> f b (bound at /tmp/Error.hs:8:32) traverse :: (a -> f b) -> A a -> f (A b) (bound at /tmp/Error.hs:8:32) }}} With `-ddump-deriv` we get this (unqualified) instance: {{{#!hs instance Traversable A where traverse f_a2Le A = pure A }}} which by itself causes the same problem in the attachment Error2.hs: {{{#!hs {-# LANGUAGE DeriveFunctor, DeriveFoldable, ImpredicativeTypes #-} import Data.Functor (Functor) import Data.Foldable (Foldable) import Data.Traversable (Traversable) data A a = A deriving (Functor, Foldable) instance Traversable A where traverse f A = pure A }}} Works fine in GHC-7.10.2 and GHC-7.10.0.20150316 and GHC-7.4 (with some additional imports), is this an `ImpredicativeTypes` regression? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11319> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer)
by GHC 23 May '18

23 May '18

#15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) -------------------------------------+------------------------------------- Reporter: awson | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After the series of SRT overhaul patches GHC doesn't work on Windows 64-bit. GHC executable crashes (AV) on any attempt to compile anything or even to start in interactive mode. When crashed it report crash address which may look not as a real address at all (e.g. 0x800 or 0xffffffffffffffff) and may report either reading from or executing such an address. OTOH, when started with, e.g. `+RTS -A256m -RTS` it is able to compile some programs (`haddock` at least). Reverting all related commits down to eb8e692cab7970c495681e14721d05ecadd21581 make things work again. I have no proof that things went bad exactly at eb8e692cab7970c495681e14721d05ecadd21581. Perhaps, this happened later on, but I have a proof that things were good immediately before. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15168> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #15173: Tests are failing with segfaults under CircleCI
by GHC 23 May '18

23 May '18

#15173: Tests are failing with segfaults under CircleCI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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 seems something has regressed recently as `master` now fails to validate on CircleCI with some tests segfaulting. Namely, {{{ T10508_api T6145 T8628 T8639_api T10052 T7478 parseTree comments listcomps literals T11430 dynCompileExpr parsed }}} all in the `normal` way. This may be due to the SRT rework. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15173> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #2893: Implement "Quantified constraints" proposal
by GHC 23 May '18

23 May '18

#2893: Implement "Quantified constraints" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5927 | Differential Rev(s): Phab:D4724 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * differential: Phab:D4353 => Phab:D4724 Comment: OK, finally I have a single squashed commit, rebased on master, ready to push to HEAD. It's in Phab:D4724. Please review! Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2893#comment:38> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15181: Levity Polymorphic type signatures in GHC.Prim
by GHC 23 May '18

23 May '18

#15181: Levity Polymorphic type signatures in GHC.Prim -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- Some of the type signatures in the haddocks for GHC.Prim are misleading. Here are a few: {{{ unsafeCoerce# :: a -> b mkWeak# :: o -> b -> (State# RealWorld -> (#State# RealWorld, c#)) -> State# RealWorld -> (#State# RealWorld, Weak# b#) raise# :: b -> o }}} The type signatures for these lead one to believe that all of the arguments must be **lifted** types, but this is not actually the case. For example, `raise#` is levity polymorphic in its returned value and should actually have the type: {{{ raise# :: forall (r :: RuntimeRep) (o :: TYPE r). b -> o }}} It's not just the haddocks that show an inaccurate type. Even in GHCi, we get this: {{{ >>> :set -XMagicHash >>> :set -fprint-explicit-kinds >>> :set -fprint-explicit-runtime-reps >>> import GHC.Exts >>> :t raise# raise# :: b -> a }}} Similarly, `unsafeCoerce#` is levity polymorphic in both types. Unfortunately, `mkWeak#` is more difficult to assign a correct type to. It should be possible for it to be broken into two separate functions (which each do the exact same thing), one of which operates on values of type `LiftedRep` and other on `UnliftedRep`. But this would be a breaking change, and it may not be worth the breakage it would introduce. At the very least, I feel like fixing `raise#` is worthwhile, since it wouldn't break anything. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15181> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15151: Better Interaction Specialization and GND
by GHC 23 May '18

23 May '18

#15151: Better Interaction Specialization and GND -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 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: -------------------------------------+------------------------------------- Let us consider the following code: {{{ -- Sort.hs sort :: (Prim a, Ord a) => MutablePrimArray s a -> ST s () sort mutArr = ... {-# SPECIALIZE sort :: MutablePrimArray s Int -> ST s () -#} {-# SPECIALIZE sort :: MutablePrimArray s Int8 -> ST s () -#} {-# SPECIALIZE sort :: MutablePrimArray s Word8 -> ST s () -#} ... }}} For reference, a `MutablePrimArray` is a `MutableByteArray` with a phantom type variable to tag the element type. This sorting algorithm may be implemented in any number of ways, and the implementation is unimportant here. The specialize pragmas are intended to capture a number of common use cases. Here's where a problem arises: {{{ -- Example.hs newtype PersonId = PersonId Int deriving (Eq,Ord,Prim) sortPeople :: MutablePrimArray s PersonId -> MutablePrimArray s PersonId sortPeople x = sort x }}} There isn't a rewrite rule that specializes the `sort` function when we are dealing with `PersonId`. So, we end up with a slower version of the code that explicitly passes all the dictionaries. One solution would be to just use `INLINABLE` instead. Then we don't have to try to list every type, and we just let the specialization be generate at the call site. But this isn't totally satisfying. There are a lot of types that are just newtype wrappers around `Int`. Why should we have an extra copy of the same code for each of them? (Even without newtypes, `INLINABLE` can still result in duplication if neither of the modules that needs a specialization transitively imports the other). What I'm suggesting is that rewrite rules (like those generated by `SPECIALIZE`) could target not just the given type but also any newtype around it, provided that all typeclass instances required by the function were the result of GND. The only situations where this is unsound are situations where the user was already doing something unsound with rewrite rules. There are several implementation difficulties: * In core, there is no good way to tell that a typeclass instance dictionary was the result of GND. I'm not sure how to work around this. * `Eq` and `Ord` usually aren't handled by the `newtype` deriving strategy. They are handled by the `stock` strategy, which produces code with equivalent behavior but is nevertheless different code. * The rewrite rule would need to look at additional arguments beyond the type arguments. I suspect that these difficulties would make such this feature difficult to implement, but this feature would help me with some of my libraries and applications. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15151> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13275: ghci ignores -fprint-explicit-runtime-reps
by GHC 23 May '18

23 May '18

#13275: ghci ignores -fprint-explicit-runtime-reps -------------------------------------+------------------------------------- Reporter: Konrad Gądek | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: levity | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The docs [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/using.html #ghc-flag--fprint-explicit-runtime-reps here] mentions the following use- case: {{{ ghci> :t ($) ($) :: (a -> b) -> a -> b ghci> :set -fprint-explicit-runtime-reps ghci> :t ($) ($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r). (a -> b) -> a -> b }}} However, I get this: {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> :t ($) ($) :: (a -> b) -> a -> b Prelude> :i ($) ($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r). (a -> b) -> a -> b -- Defined in ‘GHC.Base’ infixr 0 $ Prelude> :set -fprint-explicit-runtime-reps Prelude> :t ($) ($) :: (a -> b) -> a -> b Prelude> :i ($) ($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r). (a -> b) -> a -> b -- Defined in ‘GHC.Base’ infixr 0 $ }}} I'm not sure if the docs are wrong or GHCi is erroneously ignoring the flag when using `:t`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13275> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10089: feature: warn about unused data definitions (with typeclass instances)
by GHC 23 May '18

23 May '18

#10089: feature: warn about unused data definitions (with typeclass instances) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Let's consider an example: {{{#!hs -- M.hs: module M () where -- ghc knows about uselessness of those data D = D -- but doesn't about this: data E = E deriving (Show, Read) }}} '''ghc''' warns about useless '''D''', but not '''E''': {{{ $ ghc-7.8.4 -Wall -c M.hs -fforce-recomp M.hs:5:1: Warning: Defined but not used: type constructor or class ‘D’ M.hs:5:10: Warning: Defined but not used: data constructor ‘D’ }}} There is no way to refer to '''E''' type outside or call it's unstances, correct? I would expect no code should be generated for this module. '''ghc''' could also warn about defined, but not used instances for types, that are not exported. Some background on where those stray types come from: 1. programmer usually adds a set of data types into their program (say, 10-15 types to represent an AST) 2. then annotates them with 'deriving (Read, Show)' convenience instances 3. (months later) amends AST representation a bit and leaves leftover data types not used anywhere Does that make sense? Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10089> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8