December 2015 - ghc-tickets

[GHC] #11295: Figure out what LLVM passes are fruitful
by GHC 19 Sep '18

19 Sep '18

#11295: Figure out what LLVM passes are fruitful -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (LLVM) | 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: -------------------------------------+------------------------------------- Builds using GHC's LLVM backend are currently substantially slower than GHC's own native code generator. There are a few possible reasons for this, 1. the cost of forking processes and serializing/parsing LLVM's intermediate representation 2. the cost of the more powerful optimizations responsible for LLVM's (hopefully) better code generation 3. the cost of redundant optimizations overlapping effort already expended by GHC Given that some architecture (e.g. ARM) are only supported by LLVM and therefore suffer considerably at the hand of our slow builds, we should try to reduce # -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11295> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #11284: Lambda-lifting fails in simple Text example
by GHC 18 Sep '18

18 Sep '18

#11284: Lambda-lifting fails in simple Text example -------------------------------------+------------------------------------- Reporter: bgamari | 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: -------------------------------------+------------------------------------- Consider the example, {{{#!hs import Data.Char (isSpace) import Data.List (foldl') import GHC.Exts (build) import qualified Data.Text as T longestWord :: T.Text -> Int longestWord t = foldl' max 0 $ map T.length $ fusedWords t fusedWords :: T.Text -> [T.Text] fusedWords t0 = build $ \cons nil -> let go !t | T.null t = nil | otherwise = let (w, rest) = T.span (not . isSpace) t in cons w (go $ T.dropWhile isSpace rest) in go t0 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11284> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #10859: Generated Eq instance associates && wrongly
by GHC 18 Sep '18

18 Sep '18

#10859: Generated Eq instance associates && wrongly -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonpj Type: bug | Status: new Priority: low | 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: #10858 Differential Revisions: | -------------------------------------+------------------------------------- Currently, we derive this code for `(==)`: {{{ (==) (ImportDecl a1_acXi a2_acXj a3_acXk a4_acXl a5_acXm a6_acXn a7_acXo a8_acXp) (ImportDecl b1_acXq b2_acXr b3_acXs b4_acXt b5_acXu b6_acXv b7_acXw b8_acXx) = (((((((((a1_acXi == b1_acXq)) && ((a2_acXj == b2_acXr))) && ((a3_acXk == b3_acXs))) && ((a4_acXl == b4_acXt))) && ((a5_acXm == b5_acXu))) && ((a6_acXn == b6_acXv))) && ((a7_acXo == b7_acXw))) && ((a8_acXp == b8_acXx))) }}} To me this looks wrongly associated: Since `&&` is strict in the left but lazy in the right argument, shouldn’t this be associated the other way around? The compiler might clean it up later, but why not produce it correctly right away? The culprit is this line: {{{ = foldl1 and_Expr (zipWith3Equal "nested_eq" nested_eq tys as bs) }}} and I was just about to change that ot `foldr1`, but then I did some git- archeology and found that Simon changed that deliberately from `foldr1` to `foldl1` in changeset:8de16184643ea3c2f9f30b5eaed18db6ef247760. Simon, do you still recall what you were thinking when you applied this commit ... 18½years ago? :-) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10859> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10651: Type checking issue with existential quantification, rank-n types and constraint kinds
by GHC 16 Sep '18

16 Sep '18

#10651: Type checking issue with existential quantification, rank-n types and constraint kinds -------------------------------------+------------------------------------- Reporter: Roboguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'm trying to create a library for working with lists with existentially quantified types and I ran into an issue implementing `mapM_` for my type (note that the `map` and `mapM` implementations both work fine): {{{#!hs {-# LANGUAGE RankNTypes, ExistentialQuantification, ConstraintKinds #-} data ConstrList c = forall a. c a => a :> ConstrList c | CNil infixr :> constrMap :: (forall a. c a => a -> b) -> ConstrList c -> [b] constrMap f (x :> xs) = f x : constrMap f xs constrMap f CNil = [] constrMapM :: Monad m => (forall a. c a => a -> m b) -> ConstrList c -> m [b] constrMapM f = sequence . constrMap f -- Doesn't work, even with the definition as undefined (?) constrMapM_ :: Monad m => (forall a. c a => a -> m b) -> ConstrList c -> m () constrMapM_ = undefined }}} It fails with this error message: {{{ /users/dyoung/Test.hs:16:16: Couldn't match type ‘b0’ with ‘b’ ‘b0’ is untouchable inside the constraints (c a) bound by the type signature for constrMapM_ :: c a => a -> m b0 at /users/dyoung/Test.hs:16:16-77 ‘b’ is a rigid type variable bound by the type signature for constrMapM_ :: Monad m => (forall a. c a => a -> m b) -> ConstrList c -> m () at /users/dyoung/Test.hs:16:16 Expected type: a -> m b0 Actual type: a -> m b In the ambiguity check for the type signature for ‘constrMapM_’: constrMapM_ :: forall (c :: * -> Constraint) (m :: * -> *) b. Monad m => (forall a. c a => a -> m b) -> ConstrList c -> m () To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature for ‘constrMapM_’: constrMapM_ :: Monad m => (forall a. c a => a -> m b) -> ConstrList c -> m () Failed, modules loaded: none. }}} If I add `AllowAmbiguousTypes`, it works when the definition is `undefined` but it doesn't work if I put the real definition in. I believe that this is accepted and works as I had intended on 7.8.3 (with the correct definition as well) after talking to some people on IRC, but I haven't personally tested it. bitemyapp on IRC noticed that it does compile on 7.10.1 if we add an extra argument of type `b` to both `constrMap_` and `constrMapM` and pass that value from `constrMapM_` to `constrMap` (I think all of those things must happen in order for this to work): {{{#!hs constrMapM :: Monad m => b -> (forall a. c a => a -> m b) -> ConstrList c -> m [b] constrMapM ignoredB f = sequence . constrMap f constrMapM_ :: Monad m => b -> (forall a. c a => a -> m b) -> ConstrList c -> m () constrMapM_ b f xs = fmap (const ()) (constrMapM b f xs) }}} Is this expected behavior? I don't fully understand the new ambiguity check. This kind of reminds me of linear types (or a relevant type system) in a way: we must make explicit use of the `b` to "discharge" it in order to have a valid type. Also, I notice that this works fine as well, which makes me think it the type error above is related to `ConstraintKinds`: {{{#!hs data AnyList f = forall a. (f a) :| (AnyList f) | Nil infixr :| anyMap :: (forall a. f a -> b) -> AnyList f -> [b] anyMap f (x :| xs) = f x : anyMap f xs anyMap _ Nil = [] anyMapM :: Monad m => (forall a. f a -> m b) -> AnyList f -> m [b] anyMapM f xs = sequence (anyMap f xs) anyMapM_ :: Monad m => (forall a. f a -> m b) -> AnyList f -> m () anyMapM_ f xs = fmap (const ()) (anyMapM f xs) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10651> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11143: Feature request: Add index/read/write primops with byte offset for ByteArray#
by GHC 14 Sep '18

14 Sep '18

#11143: Feature request: Add index/read/write primops with byte offset for ByteArray# -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- Currently, primops for indexing `ByteArray#` and reading/writing `MutableByteArray#` have the following form: {{{#!hs indexTYPEArray# :: ByteArray# -> Int# -> TYPE# readTYPEArray# :: MutableByteArray# s -> Int# -> State# s -> (#State# s, TYPE##) writeTYPEArray# :: MutableByteArray# s -> Int# -> TYPE# -> State# s -> State# s }}} where second argument of type `Int#` is an offset measured in terms of the size of `TYPE#`. This is inconvinient if I want to store values of different types inside `ByteArray#`: I have to read values of type `Int8` and then glue them together with some bitwise operations. I suggest adding number of primops, similar to existing ones, which would accept offset in bytes from the start of the `ByteArray#`: {{{#!hs -- | Read 8-bit integer; offset in bytes. indexByteInt8Array# :: ByteArray# -> Int# -> Int# -- | Read 16-bit integer; offset in bytes. indexByteInt16Array# :: ByteArray# -> Int# -> Int# -- | Read 32-bit integer; offset in bytes. indexByteInt32Array# :: ByteArray# -> Int# -> Int# -- | Read 8-bit integer; offset in bytes. readInt8Array# :: MutableByteArray# s -> Int# -> State# s -> (#State# s, Int##) -- | Read 16-bit integer; offset in bytes. readInt16Array# :: MutableByteArray# s -> Int# -> State# s -> (#State# s, Int##) -- | Read 32-bit integer; offset in bytes. readInt32Array# :: MutableByteArray# s -> Int# -> State# s -> (#State# s, Int##) }}} and so on... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11143> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #10700: include/stg/Prim.h isn't C++ compatible
by GHC 14 Sep '18

14 Sep '18

#10700: include/stg/Prim.h isn't C++ compatible -------------------------------------+------------------------------------- Reporter: Fabian | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.10.1 System | Keywords: FFI | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- StgWord hs_cmpxchg8(volatile StgWord8 *x, StgWord old, StgWord new); and a few other declarations in Prim.h causes problems as they use ''new'' as a variable name. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10700> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10833: Use injective type families when dealing with givens
by GHC 14 Sep '18

14 Sep '18

#10833: Use injective type families when dealing with givens -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #6018 Differential Revisions: | -------------------------------------+------------------------------------- Consider this code: {{{#!hs type family Id a = r | r -> a id :: (Id a ~ Id b) => a -> b id x = x }}} GHC currently rejects it because it does not use type family injectivity information when dealing with the given constraints. Implementing this requires changing Core. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10833> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11197: Overeager deferred type errors
by GHC 11 Sep '18

11 Sep '18

#11197: Overeager deferred type errors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- With `TypeInType`, the solver now works in terms of unlifted equality. The only place this matters is in deferred type errors, which now are more eager than they were before. For example: {{{ {-# OPTIONS_GHC -fdefer-type-errors #-} module Main where main = do putStrLn "Hi there." putStrLn True }}} This used to print {{{ Hi there. Defer: Defer.hs:7:12: error: ... }}} Now it prints {{{ Defer: Defer.hs:7:12: error: ... }}} No more `Hi there.`. Thinking about Core, this change should be expected. GHC puts all evidence bindings for `main` at the top, and with unlifted equality in the solver, these bindings now contain `case typeError ... of ...`, which forces the type error eagerly. Previously, there was a lazy binding for a lifted equality witness, unpacked only at the last moment by magic in the desugarer, thus the lazier warning. Simon has proposed customizing the !FloatIn pass to deal with this scenario. I do believe this would work nicely, but I have not yet implemented it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11197> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #10827: GHCi should support interpeting multiple packages/units with separate DynFlags
by GHC 07 Sep '18

07 Sep '18

#10827: GHCi should support interpeting multiple packages/units with separate DynFlags -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHC API | Version: 7.11 Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Stack and other tools are attempting to make the user-experience of developing multiple packages simultaneously better. Thus, if you have source packages p, q and r (which all depend on them), `stack build` builds all of them. They are quite interested in support `stack ghci` but there are problems: https://github.com/commercialhaskell/stack/issues/665 The essence of the problem is twofold: 1. If you ask GHCi to interpret modules from multiple packages (e.g. by having multiple source directories), GHCi currently only knows how to put all of them into the same home package. This will fail if two packages have a module with the same name; also, modules in the other packages will always see modules (even if they're supposed to be hidden). 2. A GHCi session only has one global set of dynamic flags, but each package may be compiled with its own set of DynFlags (e.g. package global LANGUAGE pragmas). This means the "default DynFlags" needs to be varied between packages. It's not too obvious to me how to fix (1) (at least, you'd have to make the HPT support sets of HomeModInfos from multiple packages), but (2) seems tractable: since we already track DynFlags on a per-module basis, we just have to arrange for a "package" level DynFlag to be applied to the correct ModSummarys. Similar functionality would be useful for Backpack. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10827> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9622: GHCi command to solve a constraint
by GHC 07 Sep '18

07 Sep '18

#9622: GHCi command to solve a constraint -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 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: -------------------------------------+------------------------------------- It would be nice to have a `:solve` command for ghci that took a class constraint and returned either its derivation or an error message. A possible interface could look like so: {{{ ghci> :solve Eq (Maybe Type1, Bool) 1) instance Eq Type1 -- Defined in ‘MyModule’ 2) instance Eq a => Eq (Maybe a) -- Defined in ‘GHC.Classes’ 3) instance Eq (Maybe Type1) -- Put a ~ Int in 2) and use 1) 4) instance Eq Bool -- Defined in ‘GHC.Classes’ 5) instance (Eq a, Eq b) => Eq (a,b) -- Defined in ‘GHC.Classes’ 6) instance Eq (Maybe Type1, Bool) -- Put a ~ Maybe Type1, b ~ Bool in 5) and use 3), 4) ghci> :solve Eq (Int -> Int) No instance for Eq (Int -> Int) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9622> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2