August 2017 - ghc-tickets

[GHC] #13600: surprising error message with bang pattern
by GHC 15 Oct '18

15 Oct '18

#13600: surprising error message with bang pattern -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Poor/confusing (amd64) | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- the following code {{{ f3 :: [Int] -> IO Int f3 x = return (sum x) f4 :: [Int] -> IO Int f4 !x = return (sum x) }}} gives `The type signature for ‘f4’ lacks an accompanying binding` for the second function (the two functions are exactly the same except for the added bang). I do not understand bang patterns well, but would expect a more instructive error message. without the type definition, the second function f4 compiles with the bang). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13600> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #12430: TypeFamilyDependencies accepts invalid injectivity annotation
by GHC 15 Oct '18

15 Oct '18

#12430: TypeFamilyDependencies accepts invalid injectivity annotation -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | 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: -------------------------------------+------------------------------------- Consider this code (depends on singletons-2.2): {{{#!hs {-# LANGUAGE TypeFamilies, DataKinds, PolyKinds, TypeOperators, KindSignatures, TypeInType, TypeFamilyDependencies, UndecidableInstances #-} module Bug where import Data.Kind (Type) import Data.Singletons.Prelude (Map, SndSym0) import GHC.TypeLits (Nat) data Payload = A | B newtype NewType a = NewType Int type NatList = [(Nat, Payload)] type StripNatList (natList :: NatList) = Map SndSym0 natList type family Family (natList :: NatList) = (r :: Type) | r -> natList where Family '[] = () Family xs = NewType (StripNatList xs) }}} Why GHC is okay with injectivity annotation for `Family`: `r -> natList`? These two types: {{{#!hs type Foo = Family '[ '(0, 'A), '(1, 'B)] type Bar = Family '[ '(0, 'A), '(0, 'B)] }}} are obviously map to the same type: {{{#!hs *Bug Data.Singletons.Prelude> :kind! Foo Foo :: * = NewType ('A :$$$ '['B]) *Bug Data.Singletons.Prelude> :kind! Bar Bar :: * = NewType ('A :$$$ '['B]) }}} ---- If inline `StripNatList` inside `Family` definition: {{{#!hs type family Family (natList :: NatList) = (r :: Type) | r -> natList where Family '[] = () Family xs = NewType (Map SndSym0 xs) }}} or change `StripNatList` definition to type family: {{{#!hs type family StripNatList (natList :: NatList) where StripNatList '[] = '[] StripNatList ('(n, x) ': xs) = x ': StripNatList xs }}} compilation expectedly fails with `Type family equation violates injectivity annotation.` ---- Moreover, if I remove `NewType` from `Family` and change result kind: {{{#!hs type family Family (natList :: NatList) = (r :: [Payload]) | r -> natList where Family xs = StripNatList xs }}} it fails with correct error regardless of `StripNatList` definition. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12430> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14088: Allow users to omit`forall`
by GHC 15 Oct '18

15 Oct '18

#14088: Allow users to omit`forall` -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: -------------------------------------+------------------------------------- Just an idea I wanted to get out there, I don't think it causes parsing ambiguity {{{#!hs -- id :: forall a. a -> a id :: a. a -> a -- everywhere :: (forall b. Term b => b -> b) -> (forall a. Term a => a -> a) everywhere :: (b. Term b => b -> b) -> (a. Term a => a -> a) }}} I think it looks beautiful but clearly more difficult to Google or grep for. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14088> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12005: Constraint instances not shown in `:info`
by GHC 13 Oct '18

13 Oct '18

#12005: Constraint instances not shown in `:info` -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: -------------------------------------+------------------------------------- {{{ $ ghci -ignore-dot-ghci -XKindSignatures -XRank2Types -XConstraintKinds -XAllowAmbiguousTypes -XInstanceSigs GHCi, version 8.1.20160428: http://www.haskell.org/ghc/ :? for help Prelude> import Data.Kind Prelude Data.Kind> class Defer (p :: Constraint) where defer :: (p => r) -> r Prelude Data.Kind> instance Defer () where defer :: r -> r; defer = id Prelude Data.Kind> :i Defer class Defer (p :: Constraint) where defer :: (p => r) -> r {-# MINIMAL defer #-} -- Defined at <interactive>:2:1 }}} Same happens with the [https://github.com/ekmett/constraints/blob/master/src/Data/Constraint/Defer… Data.Constraint.Deferrable] which defines: {{{#!hs instance (Typeable a, Typeable b) => Deferrable (a ~ b) instance (Deferrable a, Deferrable b) => Deferrable (a, b) instance (Deferrable a, Deferrable b, Deferrable c) => Deferrable (a, b, c) }}} but no instances are shown: {{{ ghci> import Data.Constraint.Deferrable ghci> :i Deferrable class Deferrable (p :: Constraint) where deferEither :: proxy p -> (p => r) -> Either String r {-# MINIMAL deferEither #-} -- Defined in ‘Data.Constraint.Deferrable’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12005> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function)
by GHC 12 Oct '18

12 Oct '18

#8763: forM_ [1..N] does not get fused (10 times slower than go function) ------------------------------+-------------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Apparently idiomatic code like {{{forM_ [1.._N]}}} does not get fused away. This can give serious performance problems when unnoticed. {{{ -- Slow: forM_ [0.._N-1] $ \i -> do ... -- Around 10 times faster: loop _N $ \i -> do ... {-# INLINE loop #-} loop :: (Monad m) => Int -> (Int -> m ()) -> m () loop bex f = go 0 where go !n | n == bex = return () | otherwise = f n >> go (n+1) }}} Full code example: https://gist.github.com/nh2/8905997 - the relevant alternatives are commented. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8763> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 86

[GHC] #13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff.
by GHC 12 Oct '18

12 Oct '18

#13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff. --------------------------------------+--------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: --------------------------------------+--------------------------------- Currently GHC HEAD segfaults on Windows 64-bit when compiling `language-c-quote-0.11.7.1` package. It spits something like `Access violation in generated code when executing data at 0000000102fbcf40` (I'm using my #13108 patch here). After repeated run, when GHC hasn't recompile all files, but only part of them, it succeeds. If I delete intermediate files and repeat clean compilation, it segfaults again. Haddock always segfaults (since it always recompile all files), more details here: https://github.com/haskell/haddock/pull/568. Since these access violations consistently happen on executable data at virtual addresses above 4GB mark, this very much smells as a GHC bytecode generator/linker issue. I believe, GHC and Haddock succeed exactly when all executable addresses stay below 4GB mark. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13112> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #13923: Add a suppression flag to stop Typeable bindings being emitted with -ddump-simpl
by GHC 11 Oct '18

11 Oct '18

#13923: Add a suppression flag to stop Typeable bindings being emitted with -ddump- simpl -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: low | 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: -------------------------------------+------------------------------------- When reading core output, it is very distracting to always have to wade through a large number of bindings generated by `Typeable`. In most cases I don't care about any of these so it would be easier if there was some way to stop them being printed or being generated in the first place. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13923> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13128: Refactor AvailInfo to be more sensible
by GHC 10 Oct '18

10 Oct '18

#13128: Refactor AvailInfo to be more sensible -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: task | Status: new Priority: low | 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: -------------------------------------+------------------------------------- `AvailInfo` has been the bane of my life for the last 12 months and I want to tame it. There are two main problems with it. 1. There is this horrible invariant where if the parent is also exported then it is the first element of the list of children. 2. The set of children and field labels are represented as lists which means many expensive calls to functions from `ListSetOps`. 1 Is easy enough to solve by adding a flag which says whether the parent is exported or not. My naive attempt to solve the second problem was to replace the list by a `NameSet`. At the interface file boundary, the `NameSet` is converted into a list using `nameSetElemsStable` to maintain determinism and only pay the cost of using this expensive function once. This ran into problems in `RnModIface` where there are several functions which map over the list of children. NameSets don't support mapping and so this is difficult to implement in a satisfactory way. The next plan of attack is to distinguish between `IfaceAvailInfo` and `AvailInfo`. The former will use the old representation (lists) in order to maintain determinism but the latter will use sets. Distinguishing the two modes is useful conceptually and practically. The data type is used in quite a few different ways in lots of places which makes writing a nice interface hard. This ticket is to record my trail in case I don't make it to the end. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13128> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11368: Pattern synonym name is mangled when patterns are non-exhaustive
by GHC 10 Oct '18

10 Oct '18

#11368: Pattern synonym name is mangled when patterns are non-exhaustive ---------------------------------------+--------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 Keywords: PatternSynonyms | Operating System: Linux Architecture: x86 | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: #11367 Differential Rev(s): | Wiki Page: ---------------------------------------+--------------------------- {{{ pattern A n <- ... where A 0 = ... }}} When a pattern synonym is non-exhaustive its name is mangled: {{{ >>> A 3 "*** Exception: /tmp/tmp.t0h0pMgwWb.hs:(4,1)-(5,14): Non-exhaustive patterns in function $bA }}} “Non-exhaustive patterns in pattern synonym A” [https://ghc.haskell.org/trac/ghc/ticket/11367?replyto=5#comment:1 Comment] from ticket #11367. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11368> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10783: Partial type signatures should work with pattern synonym signatures
by GHC 10 Oct '18

10 Oct '18

#10783: Partial type signatures should work with pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE PatternSynonyms #-} pattern MyJust :: _ pattern MyJust a = Just a }}} GHC can correctly infer the type for the pattern without the type signature so (to me) it is unexpected that this inferred type is not reported to me when using partial type signatures. It just seems to not be implemented currently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10783> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5