June 2017 - ghc-tickets

[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 07 Aug '17

07 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 07 Aug '17

07 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] #13737: Have typechecking produce HsType Typechecked instead of Type
by GHC 05 Aug '17

05 Aug '17

#13737: Have typechecking produce HsType Typechecked instead of Type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | 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: -------------------------------------+------------------------------------- Right now, there is an unfortunate lack of parallelism between expressions and types. When an expression is typechecked, it is transformed from `HsExpr Name` to `HsExpr TcId`. When a type is typechecked, it is transformed from `HsType Name` to `Type`. This arrangement has served us well enough for some time, but it has several drawbacks: - Validity checking is really meant to be done over user-written syntax. This bit when implementing #11715, when validity checking couldn't tell the difference between `Int => Int` (bad) and `Int -> Int` (good). There may be other opportunities for simplification by having the user-written syntax available. - The situation above extends to type-level declarations. That is, an `HsDecl Name` for a datatype goes straight to a `TyCon`, instead of to a typechecked form of source. This is problematic because it means that all of typechecking must happen ''twice''. The first is to figure out the kind of the `TyCon` (the is the `kc` pass); the actual result is discarded. Then, typechecking is repeated with the known `TyCon` kind; this pass should always succeed and is more like desugaring than typechecking. But all the constraint generation and solving happens again. - This second pass uses knot-tied `TyCon`s, leading to `Note [Type- checking inside the knot]` in !TsHsType. If we have a form of types in `HsSyn` that occurs ''after'' typechecking, we can fix the above problems, leading both to a runtime improvement (no double-checking type declarations) and code simplification (no more typechecking in the knot). This is a significant refactor, and it should proceed in at least two stages: one for just plain types, and one for type declarations. Note that we can't produce `HsType TcTyVar`, because `Name`s in `HsType Name` sometimes become `TyCon`s and sometimes become `TcTyVar`s. We really need `HsType (TyCon + TcTyVar)` or some such. But perhaps it would be better to wait until after refactoring with respect to the Trees That Grow paper. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13737> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

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

03 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] #13689: Data.Either doesn't export INLINABLE short functions like "rights"
by GHC 03 Aug '17

03 Aug '17

#13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.0.2 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect API Unknown/Multiple | annotation Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently if I use Data.Either's simple functions like "rights", "isLeft", etc. In Core/Cmm with -O2 I see that they are called like external functions and not inlined. This is because they are not marked as INLINABLE in the library itself. It'll be great if such functions in base are marked as INLINABLE so optimizator/inliner to generate more efficient code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13689> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

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

03 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] #13731: DeriveFunctor and friends don't understand type families
by GHC 02 Aug '17

02 Aug '17

#13731: DeriveFunctor and friends don't understand type families -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE DeriveFunctor #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE TypeFamilies #-} data Test ext a where Foo :: a -> Test ext a Extend :: (ExtensionType ext a) -> Test ext a type family ExtensionType ext a data ListExtension type instance ExtensionType ListExtension a = [a] deriving instance Functor (Test ListExtension) {- a.hs:15:1: error: • Can't make a derived instance of ‘Functor (Test ListExtension)’: Constructor ‘Extend’ must use the type variable only as the last argument of a data type • In the stand-alone deriving instance for ‘Functor (Test ListExtension)’ | 15 | deriving instance Functor (Test ListExtension) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Failed, modules loaded: none. -} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13731> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

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

02 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