October 2018 - ghc-tickets

Re: [GHC] #2940: Do CSE after CorePrep
by GHC 02 Oct '18

02 Oct '18

#2940: Do CSE after CorePrep -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.10.1 Resolution: fixed | Keywords: CSE Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9291 | Differential Rev(s): Phab:D2871 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => closed * differential: => Phab:D2871 * resolution: => fixed * related: => #9291 Comment: We now do CSE after CorePrep (in STG). Closing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2940#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10793: Incorrect blocked on MVar detection
by GHC 02 Oct '18

02 Oct '18

#10793: Incorrect blocked on MVar detection -------------------------------------+------------------------------------- Reporter: | Owner: simonmar NeilMitchell | Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.1 System | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Given the code: {{{#!hs import Control.Concurrent main = do v <- newEmptyMVar forkFinally (putStrLn $ let x = x in x) (putMVar v) print =<< takeMVar v }}} The spawned thread should raise a {{{NonTermination}}} exception (assuming idle GC), then put it in the MVar {{{v}}}, which should cause the main thread to abort printing {{{Left <<loop>>}}}. However, in reality, the main thread aborts with {{{Exception: thread blocked indefinitely in an MVar operation}}}. My debugging shows that the spawned thread raises {{{NonTermination}}} and at the same time the main thread raises {{{BlockedIndefinitelyOnMVar}}}. Of course, the main thread is not really blocked on the exception, and after the finally bit runs, the MVar is filled. Adding tracing shows that the {{{putMVar}}} is called. Hypothesis is that the GC notices it can raise the non-termination exception, and then opportunistically excludes that thread from further GC scanning, and detects the MVar is unreferenced, raising the subsequent exception. Of course, given you can catch the exception, that isn't safe. Roman Leshchinskiy worries that in the wrong circumstances the MVar might really be being GC'd and thus could corrupt memory. This issue was detected while debugging an error in the Shake build system for GHC itself. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10793> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15287: T11627[ab] fail on some Darwin environments
by GHC 02 Oct '18

02 Oct '18

#15287: T11627[ab] fail on some Darwin environments -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- As of d6216443c61cee94d8ffc31ca8510a534d9406b9 I am seeing `T11627a` and `T11627b` fail in the `prof_hr` way on Darwin under CircleCI (but not Harbormaster!): {{{ Wrong exit code for T11627b(prof_hr)(expected 0 , actual 139 ) Stderr ( T11627b ): /bin/sh: line 1: 73247 Segmentation fault: 11 ./T11627b +RTS -hr -RTS +RTS -i0 -RTS *** unexpected failure for T11627b(prof_hr) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15287> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12146: syntax repair suggestion is too eager to suggest TemplateHaskell
by GHC 01 Oct '18

01 Oct '18

#12146: syntax repair suggestion is too eager to suggest TemplateHaskell -------------------------------------+------------------------------------- Reporter: j.waldmann | 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: -------------------------------------+------------------------------------- On input `ipmort Data.Monoid`, ghc's suggestion is {{{ Parse error: naked expression at top level Perhaps you intended to use TemplateHaskell }}} Apart from the nudity: the suggestion is unreasonable for beginners, and unnecessary for experts. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12146> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #8226: Remove the old style -- # Haddock comments.
by GHC 01 Oct '18

01 Oct '18

#8226: Remove the old style -- # Haddock comments. ------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Haddock 0.x supported -- # style comments for Haddock pragma and while this seems to have been long forgotten and not documented, it's still kicking in the lexer. I think this is a good time to get rid of these all together. Relevant Haddock ticket http://trac.haskell.org/haddock/ticket/171 I'll hopefully send in patches removing these from the lexer/parser tomorrow, if all goes well (unless anyone feels eager to do it, then please, you're most welcome to do so!). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8226> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11498: GHC requires kind-polymorphic signatures on class head
by GHC 01 Oct '18

01 Oct '18

#11498: GHC requires kind-polymorphic signatures on class head -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have the following compiling example: {{{ {-# LANGUAGE DataKinds, FlexibleContexts, FlexibleInstances, KindSignatures, MultiParamTypeClasses, PolyKinds, RankNTypes, ScopedTypeVariables, TypeFamilies, TypeOperators #-} import Data.Proxy import GHC.Prim type family CtxOf d (args :: k) :: Constraint class Run ctx (params :: [k]) where runAll :: Proxy params -> Proxy ctx -> (forall (args :: k) . (CtxOf ctx args) => Proxy args -> Bool) -> [Bool] data BasicCtxD type instance CtxOf BasicCtxD '(a,b) = (a ~ b) instance (Run BasicCtxD params, a ~ b) => Run BasicCtxD ( '(a,b) ': params) where runAll _ pctx f = (f (Proxy::Proxy '(a,b))) : (runAll (Proxy::Proxy params) pctx f) }}} But if I move the kind signature of `params` to its occurrence in the signature of `runAll`: {{{ class Run ctx params where runAll :: Proxy (params :: [k]) -> Proxy ctx -> (forall (args :: k) . (CtxOf ctx args) => Proxy args -> Bool) -> [Bool] }}} I get a couple of nasty (and confusing) compile errors. {{{ Main.hs:20:25: Couldn't match kind ‘k1’ with ‘(,) k k’ ‘k1’ is a rigid type variable bound by the type signature for runAll :: Proxy ('(a, b) : params) -> Proxy BasicCtxD -> (forall (args :: k1). CtxOf BasicCtxD args => Proxy args -> Bool) -> [Bool] at Main.hs:20:3 Expected type: Proxy args0 Actual type: Proxy '(a, b) Relevant bindings include f :: forall (args :: k1). CtxOf BasicCtxD args => Proxy args -> Bool (bound at Main.hs:20:17) runAll :: Proxy ('(a, b) : params) -> Proxy BasicCtxD -> (forall (args :: k1). CtxOf BasicCtxD args => Proxy args -> Bool) -> [Bool] (bound at Main.hs:20:3) In the first argument of ‘f’, namely ‘(Proxy :: Proxy '(a, b))’ In the first argument of ‘(:)’, namely ‘(f (Proxy :: Proxy '(a, b)))’ In the expression: (f (Proxy :: Proxy '(a, b))) : (runAll (Proxy :: Proxy params) pctx f) Main.hs:21:42: Could not deduce (k1 ~ (,) k k) from the context (CtxOf BasicCtxD args) bound by a type expected by the context: CtxOf BasicCtxD args => Proxy args -> Bool at Main.hs:21:8-42 ‘k1’ is a rigid type variable bound by the type signature for runAll :: Proxy ('(a, b) : params) -> Proxy BasicCtxD -> (forall (args :: k1). CtxOf BasicCtxD args => Proxy args -> Bool) -> [Bool] at Main.hs:20:3 Expected type: Proxy args -> Bool Actual type: Proxy args1 -> Bool Relevant bindings include f :: forall (args :: k1). CtxOf BasicCtxD args => Proxy args -> Bool (bound at Main.hs:20:17) runAll :: Proxy ('(a, b) : params) -> Proxy BasicCtxD -> (forall (args :: k1). CtxOf BasicCtxD args => Proxy args -> Bool) -> [Bool] (bound at Main.hs:20:3) In the third argument of ‘runAll’, namely ‘f’ In the second argument of ‘(:)’, namely ‘(runAll (Proxy :: Proxy params) pctx f)’ }}} It seems to me that the two definitions of the class are equivalent, so it would be nice if they both compiled. It wasn't obvious to me that the kind signature had to go on the class parameter rather than somewhere else. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11498> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15637: Ambiguous type variables in GeneralisedNewtypeDeriving
by GHC 01 Oct '18

01 Oct '18

#15637: Ambiguous type variables in GeneralisedNewtypeDeriving -------------------------------------+------------------------------------- Reporter: i-am-tom | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple GeneralisedNewtypeDeriving, | GeneralizedNewtypeDeriving | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When deriving the `C` instance in the following code: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE GeneralisedNewtypeDeriving #-} module Test where class C a where f :: String instance C () where f = "foo" newtype T = T () deriving C }}} The following error occurs: {{{ Test.hs:10:27: error: • Ambiguous type variable ‘a0’ arising from a use of ‘f’ prevents the constraint ‘(C a0)’ from being solved. Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instances exist: instance C T -- Defined at Test.hs:10:27 instance C () -- Defined at Test.hs:8:10 • In the third argument of ‘GHC.Prim.coerce’, namely ‘f’ In the expression: GHC.Prim.coerce @String @String f :: String In an equation for ‘f’: f = GHC.Prim.coerce @String @String f :: String When typechecking the code for ‘f’ in a derived instance for ‘C T’: To see the code I am typechecking, use -ddump-deriv | 10 | newtype T = T () deriving C | ^ }}} ... and the following core is produced: {{{ ==================== Derived instances ==================== Derived class instances: instance Test.C Test.T where Test.f = GHC.Prim.coerce @GHC.Base.String @GHC.Base.String Test.f :: GHC.Base.String Derived type family instances: }}} The problem seems to be that the `a` should have been set to `()` within the coerced instance. I've been working round this with a `newtype X a = X String` as the result value so that the `a` is present in the signature, but I think this is a bug; should a more specialised instance be generated? I hope this is enough of an explanation! Thanks, Tom -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15637> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15663: T9675 inexplicably regressed in allocations due to text submodule bump
by GHC 01 Oct '18

01 Oct '18

#15663: T9675 inexplicably regressed in allocations due to text submodule bump -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Harbormaster somehow started showing a significant (~20%) regression in `T9675`'s allocations starting in 989dca6cbd93. Strangely, this is a bump of the `text` submodule. Something is extremely fishy here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15663> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15661: Nullary constraint in GHCi breaks `:t` command
by GHC 01 Oct '18

01 Oct '18

#15661: Nullary constraint in GHCi breaks `:t` command -------------------------------------+------------------------------------- Reporter: taktoa | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.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: -------------------------------------+------------------------------------- If you create a value whose type has a nullary constraint (i.e.: a constraint that does not reference any of the type variables in scope) and then try to run `:t` on it, GHCi attempts to run instance resolution and fails before printing the type. Expected output: {{{ GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> :set -XFlexibleContexts Prelude> data Foo = Foo Prelude> let x :: (Show Foo) => () ; x = () Prelude> :t x x :: Show Foo => () }}} Actual output: {{{ GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> :set -XFlexibleContexts Prelude> data Foo = Foo Prelude> let x :: (Show Foo) => () ; x = () Prelude> :t x <interactive>:1:1: error: No instance for (Show Foo) arising from a use of ‘x’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15661> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15630: panic! Simplifier ticks exhausted
by GHC 01 Oct '18

01 Oct '18

#15630: panic! Simplifier ticks exhausted --------------------------------------+--------------------------------- Reporter: micahshahn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- Compiling the following with -O2 causes a panic. {{{#!hs module GHCPanic where data IValue = IDefault | IInt Int | IBlob String (?) :: Applicative m => (IValue -> m a) -> IValue -> m (Maybe a) (?) _ IDefault = pure Nothing (?) p x = Just <$> p x getInt :: IValue -> Either () Int getInt (IInt i) = Right i getInt v = Left () getString :: IValue -> Either () String getString (IBlob b) = Right $ b getString v = Left () (<+>) :: Applicative m => (m (a -> b), [IValue]) -> (IValue -> m a) -> (m b, [IValue]) (<+>) (f, (v:vs)) p = (f <*> (p v), vs) data TestStructure = TestStructure { _param1 :: Int , _param2 :: Maybe String , _param3 :: Maybe Int , _param4 :: Maybe String , _param5 :: Maybe Int , _param6 :: Maybe Int , _param7 :: Maybe String , _param8 :: Maybe String , _param9 :: Maybe Int , _param10 :: Maybe Int , _param11 :: Maybe String , _param12 :: Maybe String , _param13 :: Maybe Int , _param14 :: Maybe Int , _param15 :: Maybe String } getMenuItem :: [IValue] -> Either () TestStructure getMenuItem vs = fst $ (pure TestStructure, vs) <+> getInt <+> (getString ?) <+> (getInt ?) <+> (getString ?) <+> (getInt ?) <+> (getInt ?) <+> (getString ?) <+> (getString ?) <+> (getInt ?) <+> (getInt ?) <+> (getString ?) <+> (getString ?) <+> (getInt ?) <+> (getInt ?) <+> (getString ?) }}} {{{ ghc.exe: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-mingw32): Simplifier ticks exhausted When trying UnfoldingDone $j_s1y9 To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 71323 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler\utils\Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler\utils\Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler\simplCore\SimplMonad.hs:199:31 in ghc:SimplMonad }}} This seems similar to #8319 which was marked as being fixed. It compiles (albeit very very slowly!) if I remove the last parameter and the last application of (<+>). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15630> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5