April 2017 - ghc-tickets

[GHC] #8147: Exponential behavior in instance resolution on fixpoint-of-sum
by GHC 07 Aug '17

07 Aug '17

#8147: Exponential behavior in instance resolution on fixpoint-of-sum -------------------------+------------------------------------------------- Reporter: | Owner: jkoppel | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: performance, | Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Doing instance resolution on a fixpoint-of-sum type takes a very long time. This is possibly the same issue as issue #5642. These are the numbers I see for various n: {{{ 10 : 0.329s 20 : 0.479s 40 : 0.935s 80 : 2.821s 160 : 11.694s 320 : 1m30.39s 640: Ran for over 1 hour without terminating }}} This uses a couple of attached support files. Apologies for not being able to reduce further. {{{ -- Test.hs {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, UndecidableInstances, OverlappingInstances, TypeOperators, DeriveFunctor, TemplateHaskell #-} module Test where import Control.Monad import Lib import TH {- With n=3, produces data X1 e = X1 e deriving (Functor) data X2 e = X2 e deriving (Functor) data X3 e = X3 e deriving (Functor) type X = X1 :+: X2 :+: X3 -} $(let n = 320 in liftM concat $ sequence [liftM concat $ mapM mkDec $ map (('X':).show) [1..n] , makeSumType "X" (map (('X':).show) [1..n])]) data Y0 e = Y0 e deriving ( Functor ) type X' = Y0 :+: X class Lift f g where lift' :: f (Fix g) -> Fix g instance (Lift f g, Lift f' g) => Lift (f :+: f') g where lift' x = case x of L e -> lift' e R e -> lift' e instance (Functor f, f :<: g) => Lift f g where lift' = In . inj cata :: (Functor f) => (f a -> a) -> Fix f -> a cata f = f . fmap (cata f) . out lift :: Fix X -> Fix X' lift = cata lift' }}} Virtually all the time is spent in compiling lift. For example, with n=640, commenting out lift makes it compile in around 2 seconds. Interestingly, when I add the following code, compilation times only increase by 10-20%. In the original code where I encountered this issue, doing so doubles compilation time. {{{ instance Lift Y0 X where lift' = undefined lower :: Fix X' -> Fix X lower = cata lift' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8147> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13190: Add a flag to dump compiler output as JSON
by GHC 07 Aug '17

07 Aug '17

#13190: Add a flag to dump compiler output as JSON -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 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): Phab:D3010 | Wiki Page: -------------------------------------+------------------------------------- This ticket is to track the `-ddump-json` flag which is implemented by Phab:D3010. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13190> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11196: TypeInType performance regressions
by GHC 07 Aug '17

07 Aug '17

#11196: TypeInType performance regressions -------------------------------------+------------------------------------- Reporter: goldfire | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This ticket is to track the handful of performance regressions seen with the addition of `TypeInType`. It is quite possibly a good idea to break these out into separate tickets, but until we investigate, they're all bundled here. The regressions are: * T3064, bytes allocated up by 14.9% (will update description) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11196> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #13282: Introduce fast path through simplifier for static bindings
by GHC 06 Aug '17

06 Aug '17

#13282: Introduce fast path through simplifier for static bindings -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- It's not uncommon for early simplifier runs to float out a large number of "static data" bindings from a user program to the top-level. Here we will consider a top-level binding to be "static" if its RHS consists of a data constructor applied to zero or more other static bindings. This floating is quite helpful as static top-levels are represented easily as static code in object code. It also opens an interesting possibility: we know (with a few potential caveats discussed later) no further simplification of these bindings is possible. However, the simplifier currently does not take advantage of this latter fact: currently the simplifier will dutifully rebuild all bindings on every iteration. This work is wasted effort. I think it would be helpful to track the "static-ness" of top-level bindings and teach the simplifier and various analyses to ignore bindings so-marked. Also, there is one caveat here: it is currently possible for users to write rules whose LHSs are headed by a data constructor. This means that further simplification of the bindings which we deemed above as "static" **is** possible. There are two ways of dealing with this, a. Forbidding data cons in the head of a RULE's LHS b. Check the rule-base for matching rules matching a datacon as "static" -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13282> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13299: Typecheck multiple modules at the same time
by GHC 06 Aug '17

06 Aug '17

#13299: Typecheck multiple modules at the same time -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (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: -------------------------------------+------------------------------------- angerman asked me to outline how one might go about fixing #1409 (mutually recursive modules without hs-boot). Here is the most recent plan based on #10681 and discussion with SPJ. **The general approach.** Traditionally, users write hs-boot files, which compile to hi-boot files that are subsequently used for compilation. The approach that SPJ and I would like to take is to replace this step with a new one that generates hi-boot files from hs files. Everything else otherwise stays the same. **More details.** Let's suppose we have A.hs and B.hs which import each other, A imports B using a `SOURCE` import, but no B.hs-boot is defined. We ask GHC to typecheck A.hs and B.hs together to produce hi-boot files for each of the modules. To implement this, we need both a new major mode for this operation (similar to `ghc -c`); and GhcMake needs to be adjusted to call this step on every SCC in the import graph, when one or more modules in the import graph do not have an hs-boot file. This part of the implementation is a bit annoying and was what thwarted me when I've made some stabs at this issue in the past. Probably the easiest thing to do initially is to fix up GhcMake to call your new frontend (you'll put it in `HscMain`) on every SCC. An easy way to check progress here is to get `ghc --make` to print out SCCs before it starts compiling them. GHC needs to learn how to typecheck multiple modules at the same time. Let's talk a little bit about how typechecking works today: by the time we are at `HscMain` we generally have a `ModSummary` per source module to be compiled. You pass the ModSummary to something like `tcRnModule` and you get back out a `TcGblEnv` containing the results of typechecking. Look at `hscIncrementalCompile`: if you're compiling a module proper, we desugar and optimize it properly (`finish`) and then create an interface for it; if we're only typechecking (`finishTypecheckOnly`) we go straight to generating the interface file after checking. All of these functions assume, of course, that only one module is being typechecked at a time. So you must break this assumption. This comes in multiple steps. First, the actual typechecking, `tcRnModule` needs to be adjusted. Notice `tcRnModule` takes a single `HsParsedModule`; now you need to feed it multiple parsed modules. You probably want a new function for this? What should this function look like? Trace further into `initTc`: notice that the `TcGblEnv` structure assumes that there is only one module being compiled at a time `tcg_mod` (and other modules). So this assumption needs to be broken. Now, trace into the main body of typechecking `tcRnModuleTcRnM`. Normally the way we go about doing things is we rename imports, and then we rename and typecheck declarations. Clearly each of your parsed modules needs to have their imports resolved separately; furthermore, they might import each other. This needs to be made to work. I think this will have to be totally reimplemented, because you are going to have to deal with cases like: {{{ module A(T) where import B(T) module B(T) where import A(T) }}} This is obviously nonsense and your algorithm needs to identify this and kill it. Once you've done this you should have a separate `tcg_rdr_env` for each of the parsed modules. `tcRnImports` sets up a pile of other variables in `TcGblEnv` too (see bottom) and I'm not sure what should be done with those. Now we need to rename and typecheck the top-level declarations. Renaming of imported entities should proceed straightforwardly because you set up the GlobalRdrEnv correctly, but you need to give the correct module to each of the top-level declarations. Maybe assume no Template Haskell for now because I have no idea how that's supposed to work. The crux of the matter, though, is that once you've renamed all of the declarations, you now need to compute SCCs over ALL of the modules, because how else are you going to typecheck two mutually recursive declarations over two modules. At this point the one-module assumption of TcGblEnv shouldn't be a problem anymore because when we're dealing with renamed source everything knows its name. There's a little bit more about the export list (`tcRnExports`) but you've probably already handled this to handle the recursive imports correctly. Finally, what you'll get out in the end is a big pile of types from DIFFERENT modules `tcg_type_env` (and all of the other things: instances, etc. Though, I guess if an instance is defined in one module of a recursive module loop, it should be in scope everywhere?!) So now in the final stage, serializing to interface files, we need to disentangle everything and put the declarations for each module into a separate interface file per module. Maybe best to have kept them separate to begin with. To conclude, adding support for typechecking multiple modules at once will probably involve rewriting large swathes of the renamer and top-level typechecking driver, but everything past that should basically be unchanged. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13299> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13529: eventlog to report more information about stopping threads because of FFI calls
by GHC 02 Aug '17

02 Aug '17

#13529: eventlog to report more information about stopping threads because of FFI calls -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Profiling | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently eventlog file doesn't contain more information about FFI than: "stopping thread ### (making a foreign call)" It would be very-very useful if we know what actual foreign calls are made. For example: "stopping thread ### (making a foreign call to function YYYY) So we could see which function and how much time is spent on that call. If creation of threads because of in-bound foreign calls (callbacks) have which callbacks are created for it will be very useful, too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13529> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12993: GHC 8.0.2-rc2 template Haskell interface file issue
by GHC 02 Aug '17

02 Aug '17

#12993: GHC 8.0.2-rc2 template Haskell interface file issue -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I try to build language-lua as found on Hackage with GHC 8.0.2-rc2 I get the following error. This package works with 8.0.1. I'm using the latest release of cabal-install/Cabal and alex-3.2.1 {{{#!hs src/Language/Lua/Annotated/Lexer.x:149:14: error: • Can't find interface-file declaration for variable AlexTools.runA Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error • In the expression: AlexTools.runA x_a28iM inp_a28iQ x_a28iK x_a28iL mode_a28iP In the expression: case AlexTools.runA x_a28iM inp_a28iQ x_a28iK x_a28iL mode_a28iP of { (mode'_a28iR, ts_a28iS) -> (ts_a28iS ++ (go_a28iO mode'_a28iR x_a28iK)) } In a case alternative: AlexToken x_a28iK x_a28iL x_a28iM -> case AlexTools.runA x_a28iM inp_a28iQ x_a28iK x_a28iL mode_a28iP of { (mode'_a28iR, ts_a28iS) -> (ts_a28iS ++ (go_a28iO mode'_a28iR x_a28iK)) } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12993> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13327: Figure out how to make sense of Data instances for poly-kinded datatypes
by GHC 02 Aug '17

02 Aug '17

#13327: Figure out how to make sense of Data instances for poly-kinded datatypes -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #4028 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Something's funny with `Data.Data`. In particular, what instance do you expect when you write this? {{{#!hs data T phantom = T deriving Data }}} You might expect: {{{#!hs instance Typeable phantom => Data (T phantom) where ... }}} And indeed, it is possible to define a `Data` instance like this. But in practice, GHC actually derives this instance: {{{#!hs instance Data phantom => Data (T phantom) where ... dataCast1 f = gcast1 f }}} The reason is because GHC has special cases for when it derives `Data` instances for datatypes of kind `* -> *` or `* -> * -> *`. These special cases cause the derived `Data` instances to insert definitions for `dataCast1` or `dataCast2`, respectively, and their implementations (`gcast1` or `gcast2`, respectively) require the stronger instance context. See #4028 for a longer discussion about this. Things get far less predictable when you throw in `PolyKinds`, however. If you try this instead: {{{#!hs data T (phantom :: k) = T deriving Data }}} Then you do //not// get `instance Data phantom => Data (T phantom)` as above. Instead, you get this: {{{#!hs instance (Typeable k, Typeable (phantom :: k)) => Data (T phantom) where ... -- No implementation for dataCast1 }}} As it turns out, GHC's special-casing for deriving `Data` is not privy to datatypes of kind `k -> *` or `k1 -> k2 -> *`, just `* -> *` and `* -> * -> *`. This is all a bit disconcerting because if you look at `Data.Data`, there are many instances of the flavor: {{{#!hs deriving instance Data (p :: *) => Data (U1 p) -- U1 :: k -> * }}} This makes sense in a pre-`PolyKinds` world, but really, the most general type for this `Data` instance would be: {{{#!hs deriving instance (Typeable k, Typeable (p :: k)) => Data (U1 p) }}} Even worse, choosing the less polymorphic instance `Data (p :: *) => Data (U1 p)` via `StandaloneDeriving` doesn't even cause GHC to emit a definition for `dataCast1`—it just restricts the kind with no benefit! This whole situation doesn't sit well with me, especially since as we add more poly-kinded `Data` instances to `Data.Data`, we have to ask ourselves each time what the "right" `Data` instance is. It would be great if we could answer these questions: 1. Should we expand the special-casing for datatypes of kind `k -> *` or `k1 -> k2 -> *`? Or do `dataCast1` and `dataCast2` even make sense for poly-kinded datatypes? 2. Is there a way to modify `DeriveDataTypeable` such that emitting definitions for `dataCast1` and `dataCast2` don't require us to default some kind variables to `*`? Perhaps `TypeInType` could help us here somehow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13327> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13403: Derive instances (Applicative, Monad, ...) for structures lifted over functors
by GHC 01 Aug '17

01 Aug '17

#13403: Derive instances (Applicative, Monad, ...) for structures lifted over functors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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: -------------------------------------+------------------------------------- I'll start small: Given that we know how to define various instances for [https://hackage.haskell.org/package/base-4.9.1.0/docs/Data-Functor- Product.html Product] GHC could do it automatically. {{{#!hs data P f g a = f a ::: g a deriving (Functor, Applicative, Alternative) {- instance (Applicative f, Applicative g) => Applicative (P f g) where pure x = pure x ::: pure x (f:::g) <*> (x:::y) = (f <*> x) ::: (g <*> y) -} }}} And for specific constructors as well {{{#!hs data Q a = [a] :*: Maybe a deriving (Functor, Applicative, Alternative) {- instance Applicative Q where pure x = [x] :*: Just x (f:*:g) <*> (x:*:y) = (f <*> x) :*: (g <*> y) -} }}} == Alternative == Use `GeneralizedNewtypeDeriving` {{{#!hs newtype Q a = Q (Product [] Maybe a) deriving (Functor, Applicative, Alternative) pattern (:*:) :: [a] -> Maybe a -> Q a pattern a :*: b = Q (Pair a b) }}} == Future Work == This should work for a combination of various things, using `Const _` deprives us of `Alternative` {{{#!hs newtype U e a = U (([] `Product` Maybe `Product` Const e) a) deriving (Functor, Applicative) }}} using sums where [https://hackage.haskell.org/package/transformers-0.5.4.0/docs/Control- Applicative-Lift.html one summand is identity] gives us `Applicative` / `Alternative` {{{#!hs -- data Lift f a = Pure a | Other (f a) import Control.Applicative.Lift data V a = V ((Lift [] `Product` Maybe) a) deriving (Functor, Applicative, Alternative) }}} I want to be able to write this directly {{{#!hs data U e a = U [a] (Maybe a) (Const e a) deriving (Functor, Applicative) data V a = VL a (Maybe a) | VR [a] (Maybe a) deriving (Functor, Applicative, Alternative) }}} == Future, Future Work == [https://hackage.haskell.org/package/kan-extensions-5.0.1/docs/Data- Functor-Kan-Lan.html left-Kan extension] {{{#!hs data Lan g h a where Lan :: (g b -> a) -> h b -> Lan g h a deriving (Functor, Applicative) }}} [https://hackage.haskell.org/package/kan-extensions-5.0.1/docs/Control- Monad-Codensity.html codensity] {{{#!hs data Endo a = Endo (a -> a) newtype CodEndo a = CE (forall xx. (a -> Endo xx) -> Endo xx) deriving (Functor, Applicative, Monad) }}} and [https://hackage.haskell.org/package/free-4.12.4/docs/Control-Comonad- Cofree.html comonad] {{{#!hs data Rose a = a :< [Rose a] deriving (Functor, Applicative, Monad, Comonad, ...) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13403> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9522: SPECIALISE pragmas for derived instances
by GHC 01 Aug '17

01 Aug '17

#9522: SPECIALISE pragmas for derived instances -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- In package `ghc-prim`, in `GHC.Classes` we have {{{ instance (Eq a) => Eq [a] where {-# SPECIALISE instance Eq [[Char]] #-} {-# SPECIALISE instance Eq [Char] #-} {-# SPECIALISE instance Eq [Int] #-} [] == [] = True (x:xs) == (y:ys) = x == y && xs == ys _xs == _ys = False }}} The `SPECIALISE instance` pragmas instantiate the code for these commonly- used types. But for tuples we use `deriving`: {{{ deriving instance (Eq a, Eq b) => Eq (a, b) }}} and many more similar. There is no way to add a `SPECIALISE instance` pragma for a derived instance. This is bad, because they are heavily used. It should probably be possible to have a top-level {{{ {-# SPECIALISE instance Eq (Int, Bool) #-} }}} even in another module (as we can now do for functions. To do this right, we'd need to make the code for derived methods `INLINEALBE`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9522> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4