- ghc-tickets - Haskell.org

[GHC] #13293: ConstrainedClassMethods makes GeneralizedNewtypeDeriving fail
by GHC 18 Feb '17

18 Feb '17

#13293: ConstrainedClassMethods makes GeneralizedNewtypeDeriving fail -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Example: {{{ {-# language GeneralizedNewtypeDeriving #-} {-# language ConstrainedClassMethods #-} instance ToDoc Int where toDoc = undefined newtype P = P Int deriving ( ToDoc ) type Doc = () class ToDoc a where toDoc :: ToDoc a => a -> Doc }}} compile with ghc-8.0.2: {{{ C.hs:6:30: error: • Couldn't match type ‘Int’ with ‘P’ arising from the coercion of the method ‘toDoc’ from type ‘ToDoc Int => Int -> Doc’ to type ‘ToDoc P => P -> Doc’ • When deriving the instance for (ToDoc P) }}} With ghc-8.0.1, it is fine. When I drop the constraint on the method declaration, ghc-8.0.2 compiles the program. This repetition of the class constraint in the method declaration actually came from a copy-paste error, so this issue does not affect my code, but it's still puzzling. Repeating the class constraint should not change the meaning of the program? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13293> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13291: bpk15 and bkp47 fail with -dunique-increment=-1
by GHC 18 Feb '17

18 Feb '17

#13291: bpk15 and bkp47 fail with -dunique-increment=-1 -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #4012 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This happens on master. Repro command: {{{ cd testsuite/; make EXTRA_HC_OPTS='-dunique-increment=-1' TEST="bkp15 bkp47" }}} Result: {{{ Compile failed (exit code 1) errors were: [1 of 3] Processing p [1 of 1] Compiling A[sig] ( p/A.hsig, nothing ) [2 of 3] Processing q [1 of 1] Compiling A[sig] ( q/A.hsig, nothing ) [3 of 3] Processing r [1 of 2] Compiling A[sig] ( r/A.hsig, nothing ) bkp47.bkp:10:9: error: • Class ‘C’ has conflicting definitions in the module and its hsig file Main module: class C a where g :: a -> a f :: a -> a {-# MINIMAL f | g #-} Hsig file: class C a where f :: a -> a g :: a -> a {-# MINIMAL f #-} The methods do not match: The names ‘f’ and ‘g’ are different The names ‘g’ and ‘f’ are different • while merging the signatures from: • p[A=<A>]:A • q[A=<A>]:A • ...and the local signature for A bkp47.bkp:10:9: error: • Class ‘C’ has conflicting definitions in the module and its hsig file Main module: class C a where g :: a -> a f :: a -> a {-# MINIMAL f | g #-} Hsig file: class C a where f :: a -> a g :: a -> a {-# MINIMAL g #-} The methods do not match: The names ‘f’ and ‘g’ are different The names ‘g’ and ‘f’ are different • while merging the signatures from: • p[A=<A>]:A • q[A=<A>]:A • ...and the local signature for A }}} {{{ Compile failed (exit code 1) errors were: bkp15.bkp:1:26: warning: -XDatatypeContexts is deprecated: It was widely considered a misfeature, and has been removed from the Haskell language. [1 of 5] Processing p [1 of 1] Compiling H[sig] ( p/H.hsig, nothing ) [2 of 5] Processing q [1 of 1] Compiling H[sig] ( q/H.hsig, nothing ) [3 of 5] Processing r [1 of 2] Compiling H[sig] ( r/H.hsig, nothing ) bkp15.bkp:36:9: error: • Class ‘Bloop’ has conflicting definitions in the module and its hsig file Main module: class GHC.Classes.Eq a => Bloop a b | a -> b where data family GMap a (v :: * -> *) y :: a -> a -> GHC.Types.Ordering default y :: GHC.Classes.Ord a => a -> a -> GHC.Types.Ordering xa :: a -> a -> GHC.Types.Bool default xa :: a -> a -> GHC.Types.Bool {-# MINIMAL xa | y | xa | y #-} Hsig file: class GHC.Classes.Eq a => Bloop a b | a -> b where data family GMap a (v :: * -> *) xa :: a -> a -> GHC.Types.Bool default xa :: a -> a -> GHC.Types.Bool y :: a -> a -> GHC.Types.Ordering default y :: GHC.Classes.Ord a => a -> a -> GHC.Types.Ordering {-# MINIMAL xa | y #-} The methods do not match: The names ‘xa’ and ‘y’ are different The types of ‘xa’ are different The default methods associated with ‘xa’ are not compatible The names ‘y’ and ‘xa’ are different The types of ‘y’ are different The default methods associated with ‘y’ are not compatible • while merging the signatures from: • p[H=<H>]:H • q[H=<H>]:H • ...and the local signature for H bkp15.bkp:36:9: error: • Class ‘Bloop’ has conflicting definitions in the module and its hsig file Main module: class GHC.Classes.Eq a => Bloop a b | a -> b where data family GMap a (v :: * -> *) y :: a -> a -> GHC.Types.Ordering default y :: GHC.Classes.Ord a => a -> a -> GHC.Types.Ordering xa :: a -> a -> GHC.Types.Bool default xa :: a -> a -> GHC.Types.Bool {-# MINIMAL xa | y | xa | y #-} Hsig file: class GHC.Classes.Eq a => Bloop a b | a -> b where data family GMap a (v :: * -> *) xa :: a -> a -> GHC.Types.Bool default xa :: a -> a -> GHC.Types.Bool y :: a -> a -> GHC.Types.Ordering default y :: GHC.Classes.Ord a => a -> a -> GHC.Types.Ordering {-# MINIMAL xa | y #-} The methods do not match: The names ‘xa’ and ‘y’ are different The types of ‘xa’ are different The default methods associated with ‘xa’ are not compatible The names ‘y’ and ‘xa’ are different The types of ‘y’ are different The default methods associated with ‘y’ are not compatible • while merging the signatures from: • p[H=<H>]:H • q[H=<H>]:H • ...and the local signature for H }}} This indicates some dependence on Unique ordering. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13291> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7398: RULES don't apply to a newtype constructor
by GHC 18 Feb '17

18 Feb '17

#7398: RULES don't apply to a newtype constructor -------------------------------------+------------------------------------- Reporter: shachaf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6082, #10418, | Differential Rev(s): #13290 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * related: #6082, #10418 => #6082, #10418, #13290 Comment: #13290 proposes disallowing rules for constructors altogether. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7398#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13227: Loss of full laziness in mapFB
by GHC 17 Feb '17

17 Feb '17

#13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: 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've just discovered this {{{ g4 x expensive ys = let h = \7 -> y + expensive x in map h ys }}} Of course we'd expect the `(expensive x)` call to be floated out of the `\y`-abstraction, so that it is only done once. But it isn't! Here's the simplified core with -O: {{{ g4 = \ (@ b_aPG) (@ p_atr) ($dNum_aPP :: Num b) (x_arW :: p) (expensive_arX :: p -> b) (ys_arY :: [b]) -> map @ b @ b (\ (y_as0 [OS=ProbOneShot] :: b) -> + @ b $dNum_aPP y_as0 (expensive_arX x_arW)) ys_arY }}} Yikes! What is happening? Answer: look at that suspicious `ProbOneShot` on the `\y` above. Read `Note [Computing one-shot info, and ProbOneShot]` in `Demand.hs`. When `FloatOut` runs we have {{{ g4 = \ (@ b_aPL) (@ p_atw) ($dNum_aPU :: Num b) (x_as1 :: p) (expensive_as2 :: p -> b) (ys_as3 :: [b]) -> GHC.Base.build @ b (\ (@ b1_aQs) (c_aQt [OS=OneShot] :: b -> b1 -> b1) (n_aQu [OS=OneShot] :: b1) -> GHC.Base.foldr @ b @ b1 (GHC.Base.mapFB @ b @ b1 @ b c_aQt (\ (y_as5 [OS=ProbOneShot] :: b) -> + @ b $dNum_aPU y_as5 (expensive_as2 x_as1))) n_aQu ys_as3) }}} Why is the `\y` marked `ProbOneShot`? Because the occurrence analyser marked it so, based on the cardinality info from `mapFB`, even though `mapFB` was not saturated. So `Demand.argsOneShots` makes a deliberate choice to play risky, and that choice backfires badly for use of `map`. Not good! The offending commit, which introduced this behaviour, is (I think) {{{ commit 80989de947dc7edb55999456d1c1e8c337efc951 Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Fri Nov 22 17:13:05 2013 +0000 Improve the handling of used-once stuff Joachim and I are committing this onto a branch so that we can share it, but we expect to do a bit more work before merging it onto head. Nofib staus: - Most programs, no change - A few improve - A couple get worse (cacheprof, tak, rfib) Investigating the "get worse" set is what's holding up putting this on head. The major issue is this. Consider map (f g) ys where f's demand signature looks like f :: <L,C1(C1(U))> -> <L,U> -> . So 'f' is not saturated. What demand do we place on g? Answer C(C1(U)) That is, the inner C1 should stay, even though f is not saturated. I found that this made a significant difference in the demand signatures inferred in GHC.IO, which uses lots of higher-order exception handlers. I also had to add used-once demand signatures for some of the 'catch' primops, so that we know their handlers are only called once. }}} The commit isn't explicit about exactly what the "significant differences" are. Moreover note that in the comment the outer C1 is replaced by C, but nothing like that seems to happen in the code. This needs investigation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13227> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #13132: Compilation fails with a panic: get_op runContT
by GHC 17 Feb '17

17 Feb '17

#13132: Compilation fails with a panic: get_op runContT -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling 'tersmu' from Hackage fails with the following: {{{ [13 of 16] Compiling ParseM ( ParseM.hs, ParseM.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): get_op runContT Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The code can be found [https://gitlab.com/zugz/tersmu here]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13132> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #12243: RebindableSyntax and OverloadedLabels
by GHC 17 Feb '17

17 Feb '17

#12243: RebindableSyntax and OverloadedLabels -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- Should these extensions work together? I wasn't able to come up with a good motivating example; I was playing around with lenses, and thought a more restrictive class definition might aid type inference, though it turned out in that particular case it didn't. In the general case I think it might still be useful. I didn't see any discussion on this, and it seemed like maybe it's an oversight. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12243> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #4243: Make a proper options parser for the RTS
by GHC 16 Feb '17

16 Feb '17

#4243: Make a proper options parser for the RTS -------------------------------------+------------------------------------- Reporter: igloo | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 7535 Related Tickets: #9839 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): 13287# is also an effect of difference in parsing between Windows and Linux which could be fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4243#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9432: IncoherentInstances are too restricted
by GHC 16 Feb '17

16 Feb '17

#9432: IncoherentInstances are too restricted -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 7.8.2 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: -------------------------------------+------------------------------------- Hello! The reason behind using `IncoherentInstances`is that we want GHC to commit to a specific instance even if after instantiation of some variables, other instance could be more specific (http://www.haskell.org/ghc/docs/7.0.4/html/users_guide/type-class- extensions.html). There is one problem though. Lets consider following example (which could not make much sense, but shows the problem well): {{{#!haskell {-# OPTIONS_GHC -fno-warn-missing-methods #-} {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE IncoherentInstances #-} {-# LANGUAGE ScopedTypeVariables #-} module Main where import Data.Typeable -------------------------------------------------------------------------------- -- Type classes -------------------------------------------------------------------------------- class InferType a where inferType :: Proxy a -> Proxy a inferType = undefined -------------------------------------------------------------------------------- -- Proxy datatypes -------------------------------------------------------------------------------- data Id0 = Id0 deriving (Show, Typeable) data Id1 t1 = Id1 deriving (Show, Typeable) data Id2 t1 t2 = Id2 deriving (Show, Typeable) data Id3 t1 t2 t3 = Id3 deriving (Show, Typeable) data Id4 t1 t2 t3 t4 = Id4 deriving (Show, Typeable) data Id5 t1 t2 t3 t4 t5 = Id5 deriving (Show, Typeable) -------------------------------------------------------------------------------- -- Instances -------------------------------------------------------------------------------- instance InferType Int instance (InferType m, InferType a) => InferType (m a) instance (a~Id0) => InferType (a :: *) instance (a~Id1) => InferType (a :: * -> *) instance (a~Id2) => InferType (a :: * -> * -> *) -------------------------------------------------------------------------------- -- Tests -------------------------------------------------------------------------------- toProxy :: a -> Proxy a toProxy _ = Proxy --inferTypeBase :: a -> Proxy a inferTypeBase a = inferType $ toProxy a instance InferType Foo1 instance InferType Foo2 tm _ = 5 data Foo1 a = Foo1 a deriving (Show, Typeable) data Foo2 a b = Foo2 a b deriving (Show, Typeable) instance Monad Id1 -- dummy instances just for tests instance Num Id0 main = do print $ typeOf $ inferType $ toProxy $ (return (5)) print $ typeOf $ inferType $ toProxy $ (5) print $ typeOf $ inferType $ toProxy $ (Foo1 (return 5)) print $ typeOf $ inferType $ toProxy $ (Foo2 (return 5) (return 5)) print "hello" ---- OUTPUT: -- Proxy (Id1 Id0) -- Proxy Id0 -- Proxy (Foo1 (Id1 Id0)) -- Proxy (Foo2 (Id1 Id0) (Id1 Id0)) -- "hello" }}} The idea is very simple - replace all unknown type variables with known ones. It works great, but the problem appears with the function `inferTypeBase`. It should have type of `a -> Proxy a`, but GHC claims it has got `Id0 -> Proxy Id0`. It is of course caused by enabled `-XIncoherentInstances` flag, but I think GHC should be more liberal here. If it really cannot pick any instance (causing an error using only `OverlappingInstances`), the `IncoherentInstances` should allow it to pick matching one even if more specific could be available after instantianization. But If no error would occur while using `OverlappingInstances`, `IncoherentInstances` should not affect the way it resolves the instances. I think this would make `IncoherentInstances` much more useful than now. Maybe it would be good to just add some options to the flag? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9432> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13284: Incoherent instance solving is over-eager
by GHC 16 Feb '17

16 Feb '17

#13284: Incoherent instance solving is over-eager -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- danilo2 writes (originally in #9432 comment:1) {{{ {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE OverlappingInstances #-} {-# LANGUAGE IncoherentInstances #-} -- the flag is niot needed by the example module Main where import Data.Typeable class CTest a b | a -> b where cTest :: a -> b -- this instance is choosen even if more specific is available! instance out~a => CTest a out where cTest = id instance CTest Int String where cTest _ = "test" main = do print $ typeOf $ cTest (5::Int) }}} The instance `CTest a out` even if more specific `(CTest Int String)` is in scope, which just breaks how `OverlappingInstances` work. If we disable the `IncoherentInstances` flag, the right one is selected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13284> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13277: When type classes are redefined in GHCi bindings that use old instances are still accessible
by GHC 16 Feb '17

16 Feb '17

#13277: When type classes are redefined in GHCi bindings that use old instances are still accessible -------------------------------------+------------------------------------- Reporter: deech | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found the following behavior surprising: {{{#!hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /tmp/ghci7261/ghci-script Prelude> class Foo a where { foo :: a -> Int } Prelude> instance Foo () where { foo _ = 1 } Prelude> f = foo () Prelude> class Foo a where { foo :: a -> IO () } Prelude> f 1 }}} `Foo` is redefined but `f` which uses a now illegal instance of `Foo` is still accessible. I would have expected that any bindings that use the old `foo` (or have the old `foo` in their call graph) would be cleared. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13277> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1