July 2015 - ghc-tickets

[GHC] #10524: PolyKinds doesn't interact well with DeriveFunctor
by GHC 01 Aug '17

01 Aug '17

#10524: PolyKinds doesn't interact well with DeriveFunctor -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Using {{{PolyKinds}}} and {{{DeriveFunctor}}} in tandem on GHC 7.10.2-rc1 will cause a kind incompatibility in certain cases: {{{ GHCi, version 7.10.1.20150612: http://www.haskell.org/ghc/ :? for help λ> :set -XPolyKinds -XDeriveFunctor -ddump-deriv λ> newtype Compose f g a = Compose (f (g a)) deriving Functor ==================== Derived instances ==================== Derived instances: instance forall (k_axa :: BOX) (f_axb :: k_axa -> *) (g_axc :: * -> k_axa). (GHC.Base.Functor f_axb, GHC.Base.Functor g_axc) => GHC.Base.Functor (Ghci1.Compose f_axb g_axc) where GHC.Base.fmap f_axd (Ghci1.Compose a1_axe) = Ghci1.Compose (GHC.Base.fmap (GHC.Base.fmap f_axd) a1_axe) Generic representation: Generated datatypes for meta-information: Representation types: <interactive>:3:52: Kind incompatibility when matching types: f0 :: * -> * f :: k -> * Expected type: f (g b) Actual type: f0 (f1 b) Relevant bindings include a1 :: f (g a) (bound at <interactive>:3:52) fmap :: (a -> b) -> Compose f g a -> Compose f g b (bound at <interactive>:3:52) In the first argument of ‘Compose’, namely ‘fmap (fmap f) a1’ In the expression: Compose (fmap (fmap f) a1) When typechecking the code for ‘fmap’ in a derived instance for ‘Functor (Compose f g)’: To see the code I am typechecking, use -ddump-deriv }}} A workaround is to use {{{StandaloneDeriving}}}: {{{ λ> :set -XStandaloneDeriving λ> newtype Compose f g a = Compose (f (g a)) λ> deriving instance (Functor f, Functor g) => Functor (Compose f g) ==================== Derived instances ==================== Derived instances: instance (GHC.Base.Functor f_ayO, GHC.Base.Functor g_ayP) => GHC.Base.Functor (Ghci1.Compose f_ayO g_ayP) where GHC.Base.fmap f_ayQ (Ghci1.Compose a1_ayR) = Ghci1.Compose (GHC.Base.fmap (GHC.Base.fmap f_ayQ) a1_ayR) Generic representation: Generated datatypes for meta-information: Representation types: }}} This problem does not seem to occur in GHC HEAD, however: {{{ GHCi, version 7.11.20150608: http://www.haskell.org/ghc/ :? for help λ> :set -XPolyKinds -XDeriveFunctor -ddump-deriv λ> newtype Compose f g a = Compose (f (g a)) deriving Functor ==================== Derived instances ==================== Derived instances: instance forall (k_a148 :: BOX) (f_a149 :: k_a148 -> *) (g_a14a :: * -> k_a148). (GHC.Base.Functor f_a149, GHC.Base.Functor g_a14a) => GHC.Base.Functor (Ghci3.Compose f_a149 g_a14a) where GHC.Base.fmap f_a14b (Ghci3.Compose a1_a14c) = Ghci3.Compose (GHC.Base.fmap (GHC.Base.fmap f_a14b) a1_a14c) Generic representation: Generated datatypes for meta-information: Representation types: }}} Can this fix be backported in time for GHC 7.10.2? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10524> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #10561: "deriving (Functor)" on a polykinded type produces ill-kinded instance
by GHC 01 Aug '17

01 Aug '17

#10561: "deriving (Functor)" on a polykinded type produces ill-kinded instance -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Arose in #10524, and new since 7.10. {{{ rwbarton@morphism:/tmp$ ~/ghc/inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20150615: http://www.haskell.org/ghc/ :? for help Prelude> :set -XPolyKinds -XDeriveFunctor -ddump-deriv -fprint-explicit- kinds Prelude> newtype Compose f g a = Compose (f (g a)) deriving Functor ==================== Derived instances ==================== Derived instances: instance forall (k_and :: BOX) (f_ane :: k_and -> *) (g_anf :: * -> k_and). (GHC.Base.Functor f_ane, GHC.Base.Functor g_anf) => GHC.Base.Functor (Ghci1.Compose k_and * f_ane g_anf) where GHC.Base.fmap f_ang (Ghci1.Compose a1_anh) = Ghci1.Compose (GHC.Base.fmap (GHC.Base.fmap f_ang) a1_anh) Generic representation: Generated datatypes for meta-information: Representation types: Prelude> :i GHC.Base.Functor class Functor (f :: * -> *) where [...] }}} The context `(GHC.Base.Functor f_ane, GHC.Base.Functor g_anf)` is ill- kinded except when `k_and = *`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10561> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9020: Massive blowup of code size on trivial program
by GHC 31 Jul '17

31 Jul '17

#9020: Massive blowup of code size on trivial program ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The test `simplCore/should_compile/simpl015` was leading to massive compile times. This is weird: it looks like: {{{ main = do { return () ; return () ... hundreds more times ... ; return () } }}} It turns out that the cause was over-eager eta-expansion. Each `return ()` gives a top-level PAP thus {{{ lvl17 :: IO () lvl17 = returnIO () }}} But these definitions are then eta-expanded, thus: {{{ lvl17 = ((\eta. returnIO () |> sym g) eta) |> g where g :: State# RealWorld -> (# State# RealWorld, () #) ~ IO () }}} Now in general it makes sense to eta-expand through newtypes (as is done here), because it exposes more lambadas. But it really doesn't make sense to eta-expand a PAP like this. Fortunately the fix is easy: use `exprArity` rather than `manifestArity` in `SimplUtils.tryEtaExpandRhs`. The effect on `simpl015` is dramatic: compiler allocation drops from 6.6G to 812M; and residency drops from 1.8G to 45M. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9020> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #10684: Error cascade when unrelated class derivation fails
by GHC 25 Jul '17

25 Jul '17

#10684: Error cascade when unrelated class derivation fails -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Pretty minor bug, but I thought I'd point it out: {{{ module A where import Data.Typeable data A = A deriving (Show, Typeable) data B = B A deriving (Show) }}} I get two errors when I expect one: {{{ A.hs:3:28: Can't make a derived instance of `Typeable A': You need -XDeriveDataTypeable to derive an instance for this class In the data declaration for `A' A.hs:4:24: No instance for (Show A) arising from the 'deriving' clause of a data type declaration Possible fix: add an instance declaration for (Show A) or use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Show B) }}} The failed Typeable derivation also causes the Show derivation to fail, which causes an error later in the file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10684> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10064: Add support for "foo"## literals to MagicHash
by GHC 24 Jul '17

24 Jul '17

#10064: Add support for "foo"## literals to MagicHash -------------------------------------+------------------------------------- Reporter: chadaustin | 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: | -------------------------------------+------------------------------------- I'm working on a high-performance library for building up buffers of data. Appending ByteStrings works pretty well, but, for bytestring literals, it's faster to avoid the CAF (and it's associated tag check + indirect jump) entirely and append a zero-terminate MagicHash string literal via Addr#. Then I discovered that it's 30% faster if you can avoid the strlen with an explicit length. See this benchmark: https://github.com/chadaustin /buffer- builder/blob/ac662962d6d3c21f206ab8e8121323b9f18677fa/bench/Bench.hs#L42 That API is not very pleasant, of course. :) Thus, here is a feature request: It would be great if "foo"## produced (# Int#, Addr# #), where the Int# is the length of the buffer in bytes. The compiler could enforce that the literal only contains 8-bit values. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10064> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9453: The example for GHC Generics is kinda broken
by GHC 24 Jul '17

24 Jul '17

#9453: The example for GHC Generics is kinda broken -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- From http://www.reddit.com/r/haskell/comments/2douzn/problem_with_popular_ghcgen…: The popular GHC.Generics serialization example at http://www.haskell.org/ghc/docs/latest/html/users_guide/generic- programming.html#idp25226064 illustrates how to serialize a sum datatype (a :+: b), with a 0 bit representing a and a 1 bit representing b. However, consider a :+: b :+: c. If the compiler treats this as (a :+: b) :+: c, then a is 00, b is 01, c is 1. If it's a :+: (b :+: c), then a is 0, b is 10, c is 11. The compiler's decision, even though (as I understand it) consistent for any given compile, could differ later. The manual, at http://hackage.haskell.org/package/generic- deriving-1.6.3/docs/Generics-Deriving-Base.html#g:9 states not to depend on the ordering, which the example does. I think this is a valid concern, and the manual should be at least updated to discuss this problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9453> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8903: Add dead store elimination
by GHC 18 Jul '17

18 Jul '17

#8903: Add dead store elimination ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- We could use some dead store elimination in the code generator. Here's some Cmm that has redundant stores to the same locations: {{{ // thawArray#: I64[Hp - 168] = I64[PicBaseReg + stg_MUT_ARR_PTRS_DIRTY_info@GOTPCREL]; I64[Hp - 160] = 16; I64[Hp - 152] = 17; _c2nT::I64 = Hp - 168; call MO_Memcpy(_c2nT::I64 + 24, _s2cx::P64 + 24, 128, 8); // writeArray#: P64[(_c2nT::I64 + 24) + (_s2cy::I64 << 3)] = _s2cE::P64; I64[_c2nT::I64] = I64[PicBaseReg + stg_MUT_ARR_PTRS_DIRTY_info@GOTPCREL]; I8[(_c2nT::I64 + 24) + ((I64[_c2nT::I64 + 8] << 3) + (_s2cy::I64 >> 7))] = 1 :: W8; // unsafeFreeze# I64[_c2nT::I64] = I64[PicBaseReg + stg_MUT_ARR_PTRS_FROZEN0_info@GOTPCREL]; }}} There are three stores to the same location (`I64[_c2nT::I64]`). (There's also one much less obvious double store to another location, which will probably be much harder to address: the store to `P64[(_c2nT::I64 + 24) + (_s2cy::I64 << 3)]` overwrites a word previous written by the `MO_Memcpy`. Getting to that one will be hard as the memcoy callish !MachOp only gets expanded in the backend.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8903> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9630: compile-time performance regression (probably due to Generics)
by GHC 18 Jul '17

18 Jul '17

#9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time performance bug Related Tickets: #9583 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This is a continuation of #9583 Compiling latest Cabal from Git's `Language.Haskell.Extension` module shows a significant performance regression with respect to GHC 7.8.3: {{{ $ uname -a Linux duo 3.17.0-031700rc6-generic #201409211935 SMP Sun Sep 21 23:37:11 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ git describe cabal-install_merged-1912-g7161e4c ######################################################################################## $ /opt/ghc/7.8.3/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 $ /opt/ghc/7.8.3/bin/ghc -Rghc-timing -O -c Language/Haskell/Extension.hs <<ghc: 5228751760 bytes, 543 GCs, 34135677/114940864 avg/max bytes residency (14 samples), 273M in use, 0.00 INIT (0.03 elapsed), 4.96 MUT (5.28 elapsed), 3.26 GC (3.47 elapsed) :ghc>> ######################################################################################## $ /opt/ghc/head/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 7.9.20140923 $ /opt/ghc/head/bin/ghc -Rghc-timing -O -c Language/Haskell/Extension.hs <<ghc: 125917854120 bytes, 3181 GCs, 349136895/833496072 avg/max bytes residency (30 samples), 2096M in use, 0.001 INIT (0.001 elapsed), 133.003 MUT (142.730 elapsed), 73.241 GC (78.234 elapsed) :ghc>> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9630> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 66

[GHC] #9805: Use TrieMaps to speed up type class instance lookup
by GHC 18 Jul '17

18 Jul '17

#9805: Use TrieMaps to speed up type class instance lookup -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, type class instance resolution is performed by doing a map lookup by type class, and then linearly matching against every instance. This is not great, and for a while, simonpj has been keen on using the TrieMap data structure in GHC, which has been previously used to implement a map from CoreExprs to various things (e.g. for CSE). What makes this a little tricky is that instance lookup isn't intended to be an exact match: we should unify so-called template variables and provide a substitution; furthermore, there may be multiple matches. After some prototyping, I think we should be able to make this work. The primary refactoring we have to do is *maintain the key associated with an entry in a TrieMap*. Unlike the current uses of TrieMaps, where it's acceptable to lose the underlying key associated with an entry in the TrieMap, we need to know the key when doing unification, because it may be reported in the substitution. There are a few knock-on effects of this: * We should add a method `foldWithKeyTM :: (Key m -> a -> b -> b) -> m a -> b -> b` to the `TrieMap` type class. * We need a variant of `UniqFM` which tracks the original key that was used. I propose we name it `UniqKM` (unique key map). A number of implementations of `TrieMap` need to be adjusted to use this instead of `UniqFM`. * Why can't we just represent keyed TrieMaps as `TypeMap (Type, a)`? It might be possible. An insurmountable difficulty would be if we need to know the partial key PRIOR to having finished traversing the TrieMap; however, for the parts of the unification algorithm I've implemented, this does not seem to be the case. The primary actual difficulty is that `Type` uses a named representation, whereas `TypeMap` keys are on-the-fly deBruijn numbered. There would at least be some annoying fiddliness. * Reversing the deBruijn numbered key into a `Type` is a bit goofy. Essentially, you need the reverse of the current `CmEnv`: a mapping from de Bruijn levels to the `Var` you've decided to allocate. (I've called this `CfEnv` in my prototype) * When we represent a TrieMap binder, we have to put the binder map on the OUTSIDE, as opposed to the inside as it is currently. Otherwise, we can't update the `CfEnv` with the new mapping before making the recursive call to fold-with-key. I'll attach the standalone Haskell file I used to prototype this, wherein I copy-pasted a lot of Haskell from GHC's source and implemented fuzzy map on a simplified version of `Type`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9805> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #8346: Rank 1 type signature still requires RankNTypes
by GHC 11 Jul '17

11 Jul '17

#8346: Rank 1 type signature still requires RankNTypes ----------------------------+---------------------------------------------- Reporter: | Owner: tinctorius | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #2605 | ----------------------------+---------------------------------------------- When trying to figure out which type variable names are *actually* bound in `ScopedTypeVariables`, I tried floating `forall`s into the covariant argument of the function type. Essentially, I ran into the problem that programs like the following are rejected: {{{ #!hs {-# LANGUAGE ExplicitForAll #-} tuple :: forall a. a -> (forall b. b -> (a, b)) tuple = (,) }}} The message is as follows: {{{ Main.hs:2:10: Illegal polymorphic or qualified type: forall b. b -> (a, b) Perhaps you intended to use -XRankNTypes or -XRank2Types In the type signature for `tuple': tuple :: forall a. a -> (forall b. b -> (a, b)) }}} As far as I know, the rank of a type is defined by how deep quantifiers are nested in contravariant parts of that type. Or something like that. Also, as far as I know, `forall a. a -> (forall b. b -> (a, b))` is equivalent to `forall a b. a -> b -> (a, b)`, and more importantly, both are rank-1 polymorphic. There should be no need to use extensions that allow higher-ranked polymorphism. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8346> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4