November 2016 - ghc-tickets

[GHC] #10619: Order matters when type-checking
by GHC 24 Apr '17

24 Apr '17

#10619: Order matters when type-checking -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE RankNTypes #-} module Bug where foo True = (\x -> x) :: (forall a. a -> a) -> forall b. b -> b foo False = \y -> y }}} the module compiles. But when I say {{{ {-# LANGUAGE RankNTypes #-} module Bug where foo False = \y -> y foo True = (\x -> x) :: (forall a. a -> a) -> forall b. b -> b }}} it doesn't, failing with {{{ Bug.hs:6:13: Couldn't match type ‘b0 -> b0’ with ‘forall a. a -> a’ Expected type: (forall a. a -> a) -> forall a. a -> a Actual type: (forall a. a -> a) -> b0 -> b0 In the expression: (\ x -> x) :: (forall a. a -> a) -> forall b. b -> b In an equation for ‘foo’: foo True = (\ x -> x) :: (forall a. a -> a) -> forall b. b -> b }}} I believe this behavior stems from the special case in `tcMonoBinds`, for non-recursive functions without a type signature. I believe the bug would be fixed if that function also checks to make sure that there is precisely one clause to the function. Do you agree? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10619> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9210: "overlapping instances" through FunctionalDependencies
by GHC 21 Apr '17

21 Apr '17

#9210: "overlapping instances" through FunctionalDependencies -------------------------------------------+------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- This program prints `("1",2)`, but if you reverse the order of the two instances, it prints `(1,"2")`. {{{ {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} -- extracted from http://lpaste.net/105656 import Control.Applicative import Data.Functor.Identity modify :: ((a -> Identity b) -> s -> Identity t) -> (a -> b) -> (s -> t) modify l f s = runIdentity (l (Identity . f) s) class Foo s t a b | a b s -> t where foo :: Applicative f => (a -> f b) -> s -> f t instance Foo (x, a) (y, a) x y where foo f (a,b) = (\fa -> (fa,b)) <$> f a instance Foo (a, x) (a, y) x y where foo f (a,b) = (\fb -> (a,fb)) <$> f b main = print $ modify foo (show :: Int -> String) (1 :: Int, 2 :: Int) }}} Note that the two instances involved `Foo (Int, Int) (String, Int) Int String` and `Foo (Int, Int) (Int, String) Int String` are not actually overlapping. But, they have the same `a`, `b`, and `s` fields and it seems that this makes GHC think that either one is equally valid, thanks to the fundep. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9210> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9456: Weird behavior with polymorphic function involving existential quantification and GADTs
by GHC 19 Apr '17

19 Apr '17

#9456: Weird behavior with polymorphic function involving existential quantification and GADTs -------------------------------------+------------------------------------- Reporter: haasn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This program is rejected by GHC 7.8.2: {{{ {-# LANGUAGE GADTs, ExistentialQuantification #-} module Foo where data Box = forall a. Box a foo :: Monad m => m () foo = do box <- return (Box ()) let f x = let _ = Box x `asTypeOf` box in x g :: a -> a g = f return () }}} With the following type error: {{{ foo.hs:15:11: Couldn't match type ‘a0’ with ‘a’ because type variable ‘a’ would escape its scope This (rigid, skolem) type variable is bound by the type signature for g :: a -> a at foo.hs:14:12-17 Expected type: a -> a Actual type: a0 -> a0 Relevant bindings include g :: a -> a (bound at foo.hs:15:7) f :: a0 -> a0 (bound at foo.hs:10:7) In the expression: f In an equation for ‘g’: g = f }}} Perplexingly, however, you can get it to compile either by adding a type signature to f: {{{ {-# LANGUAGE GADTs, ExistentialQuantification #-} module Foo where data Box = forall a. Box a foo :: Monad m => m () foo = do box <- return (Box ()) let f :: x -> x f x = let _ = Box x `asTypeOf` box in x g :: a -> a g = f return () }}} Or by disabling the GADTs extension: {{{ {-# LANGUAGE ExistentialQuantification #-} module Foo where data Box = forall a. Box a foo :: Monad m => m () foo = do box <- return (Box ()) let f x = let _ = Box x `asTypeOf` box in x g :: a -> a g = f return () }}} Or by getting rid of the asTypeOf: {{{ {-# LANGUAGE GADTs, ExistentialQuantification #-} module Foo where data Box = forall a. Box a foo :: Monad m => m () foo = do box <- return (Box ()) let f x = let _ = Box x in x g :: a -> a g = f return () }}} Or by defining ‘box’ differently: {{{ {-# LANGUAGE GADTs, ExistentialQuantification #-} module Foo where data Box = forall a. Box a foo :: Monad m => m () foo = do let box = Box () let f x = let _ = Box x `asTypeOf` box in x g :: a -> a g = f return () }}} And perhaps some other factors that I haven't tested yet. It appears to me that all of these should be valid programs. Real world source: https://github.com/andygill/io- reactive/blob/master/Control/Concurrent/Reactive.hs It happens here due to the usage of (putMVar box ret), which makes the function requestit in line 77 not as polymorphic as it should be, unless you add a type signature. The putMVar serves the same role as the `asTypeOf` in my smaller example. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9456> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9605: Misleading error message with forgotten "do"
by GHC 19 Apr '17

19 Apr '17

#9605: Misleading error message with forgotten "do" -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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 the following (simplified) code, I forgot to add the do keyword, when doing some refactoring. This caused GHC to give a strange error message that said approximately "The function F is applied to two arguments, but its type T has only two"... which is odd! {{{#!hs import Control.Monad.RWS ( evalRWS, RWS ) import Control.Monad.Writer.Class ( tell ) main = print $ evalRWS (go 1) () () go :: Int -> RWS () [String] () () go i = --Oops, forgot a do here return (show i) >>= (\l -> tell [l]) -- go $ i + 1 go i }}} Strangely, replacing the "go i" line with the commented-out line above it gives a sensible error message, the "Possible cause: `\l -> tell [l]' is applied to too many arguments" message, which is correct, and would've pointed me straight to the problem. The invalid error message, which appears to be the same using GHC 7.6.3 and 7.8.3, is: {{{ NFA.hs:8:25: Couldn't match type ‘String -> Control.Monad.Trans.RWS.Lazy.RWST () [String] () Data.Functor.Identity.Identity ()’ with ‘()’ Expected type: Int -> String -> Control.Monad.Trans.RWS.Lazy.RWST () [String] () Data.Functor.Identity.Identity () Actual type: Int -> () The function ‘\ l -> tell [l]’ is applied to two arguments, but its type ‘(Int -> RWS () [String] () ()) -> Int -> ()’ has only two In the second argument of ‘(>>=)’, namely ‘(\ l -> tell [l]) go i’ In the expression: return (show i) >>= (\ l -> tell [l]) go i }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9605> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10450: RankNTypes type check on pattern match of "let" behaves different from "case"
by GHC 19 Apr '17

19 Apr '17

#10450: RankNTypes type check on pattern match of "let" behaves different from "case" -------------------------------------+------------------------------------- Reporter: sjcjoosten | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Operating System: Unknown/Multiple Keywords: RankNTypes | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When pattern matching, "let/where" and "case" have different behaviours. I believe this to be a bug, and my hope is that all of the following should be accepted. Currently, this is accepted (a version using 'where' instead of 'let' type-checks too): {{{#!hs {-# LANGUAGE RankNTypes, ScopedTypeVariables #-} module Main where data Phantom x = Phantom Int deriving Show foo :: forall y. (forall x. (Phantom x)) -> Phantom y foo (Phantom x) = Phantom (x+1) -- trying to map foo over a list, this is the only way I can get it to work typeAnnotatedMap :: (forall x. [Phantom x]) -> [Phantom y] typeAnnotatedMap intList = case intList of [] -> [] _ -> let (phead:ptail) = intList in foo phead : typeAnnotatedMap ptail }}} The following are not accepted: {{{#!hs typeAnnotatedMap :: (forall x. [Phantom x]) -> [Phantom y] typeAnnotatedMap intList = case intList of [] -> [] (phead:ptail) -> foo phead : typeAnnotatedMap ptail typeAnnotatedMap :: (forall x. [Phantom x]) -> [Phantom y] typeAnnotatedMap [] = [] typeAnnotatedMap (phead:ptail) = foo phead : typeAnnotatedMap ptail }}} The switches "ImpredicativeTypes" and "NoImpredicativeTypes" only change GHC's behaviour in the following example, for which I understand (but don't like) that it is not accepted, its error message is fine: {{{#!hs typeAnnotatedMap :: (forall x. [Phantom x]) -> [Phantom y] typeAnnotatedMap lst = map foo lst }}} Tested this on 7.8.2. Version 7.6.3 and 7.4.2 seem to behave the same. Sorry for not testing this on the latest version. Should this not be a bug, it would help if the type checker would somehow point me in the direction of the solution (first version) when I write any one of the 'problem cases'. The current type error is something like: {{{ Couldn't match type ‘x0’ with ‘x’ because type variable ‘x’ would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: [Phantom x] }}} More helpful would be something like: {{{ Your pattern match bound the following types to a shared skolem variable: ptail :: [Phantom x0] (bound at rankNtest.hs:11:25) phead :: Phantom x0 (bound at rankNtest.hs:11:19) You may have intended to use a "let" or "where" pattern-match instead. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10450> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10227: Type checker cannot deduce type
by GHC 19 Apr '17

19 Apr '17

#10227: Type checker cannot deduce type -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When using closed type families the type checker does not use all the information that the closedness condition implies. In the following module the type checker fails to deduce the type for `f`. But lets start with `descrIn` since it has the same problem. The deduced type is `(D d Bool ~ Bool, D d Double ~ Bool, D d (Maybe String) ~ Bool) => Descr d`. But it is (to quote Simon PJ) plain as a pikestaff that `D d Double ~ Bool` can only hold if `d ~ In`, since there are only two equations and it cannot be the second. Similar reasoning can be used to deduce all the commented out type signatures. {{{#!hs {-# LANGUAGE RecordWildCards, TypeFamilies, DataKinds, NoMonomorphismRestriction, FlexibleContexts #-} module Main(main) where import Data.Maybe data InOut = In | Out type family D (d :: InOut) a where D 'In a = Bool D 'Out a = a data Descr d = Descr { abc :: D d Bool, def :: D d Double, ghi :: D d (Maybe String) } --descrIn :: Descr 'In descrIn = Descr { abc = False, def = True, ghi = True } --f :: Descr 'Out -> Double f Descr{..} = def + read (fromMaybe "0" ghi) --g :: Descr 'In -> Descr 'Out g d = Descr { abc = if abc d then True else False, def = if def d then 1234 else 0, ghi = if ghi d then Just "3008" else Nothing } main :: IO () main = do print $ f $ g descrIn }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10227> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11511: Type family producing infinite type accepted as injective
by GHC 19 Apr '17

19 Apr '17

#11511: Type family producing infinite type accepted as injective -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: TypeFamilies, | Operating System: Unknown/Multiple Injective | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A question came up during discussion at University of Wrocław: {{{#!hs type family F a = r | r -> a where F a = [F a] }}} Should this pass the injectivity check? Currently it does but I don't think this is correct. After all `F Bool` and `F Char` both reduce to the same infinite type `[[[...]]]`, which by definition of injectivity gives us `Char ~ Bool`. Is this dangerous in practice? It can cause reduction stack overflow (or an infinite loop if you disable that check) but I don't think this can be used to construct unsafe coerce. We'd have to unify two infinite types, which does not seem possible. This is not an implementation problem - this stays faithful to theory developed in injective type families paper. If others agree that this is indeed incorrect then I think the right solution here would be to drop equation (7) from our algorithm in the paper. For generalized injectivity we planned drop that equation anyway. Here's another reason for doing this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11511> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12781: Significantly higher allocation with INLINE vs NOINLINE
by GHC 18 Apr '17

18 Apr '17

#12781: Significantly higher allocation with INLINE vs NOINLINE -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program allocates much more memory ("bytes allocated in the heap") in its current form than with INLINE replaced by NOINLINE, as in the comment. That may be normal, but virtually every feature of this example is needed to trigger the behaviour and so I have no clear idea which language feature is responsible and should be avoided and, consequently, how to optimize my much more complex codebase (in which INLINES of once used functions tend to help and sometimes significantly so). As a comment to this ticket I will post another example, where the difference in allocation is pumped to a factor of 2000, as a proof that the issue is serious. {{{ {-# LANGUAGE RankNTypes #-} import Control.Monad.ST.Strict import qualified Data.IntMap.Strict as IM -- ghc --make -O1 InlineBloat.hs; ./InlineBloat +RTS -s data P = P Int instance Enum P where fromEnum (P x) = x toEnum n = undefined main = do let {-# NOINLINE z #-} z = 44 dis :: Int -> () {-# INLINE dis #-} -- change here to NOINLINE and observe lower alloc dis pI = let p0 = let (_, x) = pI `quotRem` z in P x p1 = let (_, x) = pI `quotRem` z in P x m = IM.lookup (fromEnum p0) IM.empty b = IM.member (fromEnum p1) IM.empty in m == Just 'c' `seq` b `seq` () {-# NOINLINE l #-} l = [0..10000000] mapVT :: forall s. () -> ST s () {-# INLINE mapVT #-} mapVT _ = mapM_ (\x -> return $! dis x) l return $! runST (mapVT ()) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12781> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8426: one-shot compilation + TH doesn't see instances that is seen in batch mode
by GHC 15 Apr '17

15 Apr '17

#8426: one-shot compilation + TH doesn't see instances that is seen in batch mode ----------------------------------------------+---------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Other Blocked By: | Test Case: Related Tickets: #7867 | Blocking: ----------------------------------------------+---------------------------- Haskell prime and Haskell98 both states that instances are always seen if there is any chain of imports leading from the current module to the instance. http://darcs.haskell.org/haskell-prime-report/report/haskell-report- html/modules.html#import-instances The ghc manual contains a discussion why this specification is too performance heavy to näively implement and contains the definition of orphanness and an algorithm to reproduce the specification with better performance. http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/separate- compilation.html#orphan-modules Unfortunately this cleverness breaks template haskell. Namely, if: - `Class.hs` contains a class, - `NonOrphan.hs` contains a data that implements the class, - `Importer.hs` just imports `NonOrphan.hs`, - `Main.hs` imports `Importer.hs`, - `Main.hs` reifies the class; then: - one-shot compilation's reify doesn't see the instance, - batch compilation's reify sees the instance. This ambiguity is shown in the attached tgz. Furthermore if `NonOrphan.hs` is in a separate package, then of course even batch compilation mode wouldn't reify the instance correctly. In that case there is no disambiguity between one-shot and batch, simply both is missing the info. I propose to solve this by enforcing a loading of all the interface files for every import transitively for the current module, when we meet an open type family or class reification request in template haskell's reify handler in `TcSplice.hs`. So I propose to keep the optimization of orphan instances and use it 99.9% of the time. We would only ever go on the quest of reading interface files for every import transitively when the user tries to reify something where we have to return an instance list. This means that TH compilations that reify types will get a little bit slower in exchange of being correct and unambiguous. Compilation time in cases when TH reification is not used will not change. I volunteer to prepare the patch, but would like to hear others first. So, any opinions, alternative ideas? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8426> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10800: vector-0.11
by GHC 13 Apr '17

13 Apr '17

#10800: vector-0.11 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- vector-0.11 takes substantially longer to compile with 7.10 than 7.8 Unfortunately the issue appears to be in generated code. Lacking time right now so I'm just going to drop the IRC log here, Compile log: https://travis-ci.org/haskell/vector/builds/56179052 {{{ * hvr thought some compile-time improvements landed in 7.10.2 <dolio> I don't think it uses sufficiently less memory to prevent it from using all memory on travis and failing. <dolio> Which is why it suddenly went from 8 minutes to 35. <dolio> Although it's also significantly worse even when you have enough memory. <dolio> hvr: 7.8.4 takes 4m40s, 7.10.2 takes 16m40s. <dolio> i7 4770, 32GB RAM. <dolio> vector 0.11 branch. <dolio> It's not as bad in the 0.10 branch. <dolio> It uses like 60% more memory, too. <dolio> Maybe more. <dolio> It's really just one or two files in the test suite that take all the time/memory. <hvr> dolio: does vector do some aggressive INLINEing? <dolio> Well, yes. <hvr> more in 0.11 than in 0.10? <dolio> It does more stuff in 0.11, yes. <bgamari> vector 0.11 has this new chunked streaming abstraction IIRC <hvr> there's a generic one though iirc <dolio> 0.11 introduced the generalized stream fusion, so there's like three different things going on that specialization has to select one of. <dolio> Instead of just one thing like in 0.10. <dolio> Anyhow, the problem file(s) generate a bunch of tests using template Haskell, so they're pretty opaque. <dolio> I'm pretty sure it's the generated code that's the problem, though. <dolio> Not the template haskell that generates it. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10800> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22