January 2019 - ghc-tickets

[GHC] #16188: GHC HEAD-only panic (buildKindCoercion)
by GHC 04 Mar '19

04 Mar '19

#16188: GHC HEAD-only panic (buildKindCoercion) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.7 (Type checker) | Keywords: TypeInType | 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: -------------------------------------+------------------------------------- The following program compiles without issue on GHC 8.6.3: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Data.Kind (Type) import Data.Type.Bool (type (&&)) data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type infixr 0 ~> type family Apply (f :: a ~> b) (x :: a) :: b data family Sing :: forall k. k -> Type data instance Sing :: Bool -> Type where SFalse :: Sing False STrue :: Sing True (%&&) :: forall (x :: Bool) (y :: Bool). Sing x -> Sing y -> Sing (x && y) SFalse %&& _ = SFalse STrue %&& a = a data RegExp :: Type -> Type where App :: RegExp t -> RegExp t -> RegExp t data instance Sing :: forall t. RegExp t -> Type where SApp :: Sing re1 -> Sing re2 -> Sing (App re1 re2) data ReNotEmptySym0 :: forall t. RegExp t ~> Bool type instance Apply ReNotEmptySym0 r = ReNotEmpty r type family ReNotEmpty (r :: RegExp t) :: Bool where ReNotEmpty (App re1 re2) = ReNotEmpty re1 && ReNotEmpty re2 sReNotEmpty :: forall t (r :: RegExp t). Sing r -> Sing (Apply ReNotEmptySym0 r :: Bool) sReNotEmpty (SApp sre1 sre2) = sReNotEmpty sre1 %&& sReNotEmpty sre2 blah :: forall (t :: Type) (re :: RegExp t). Sing re -> () blah (SApp sre1 sre2) = case (sReNotEmpty sre1, sReNotEmpty sre2) of (STrue, STrue) -> () }}} However, it panics on GHC HEAD: {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20190114 for x86_64-unknown-linux): buildKindCoercion Any ReNotEmpty re2_a1hm Bool t_a1hg Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1159:37 in ghc:Outputable pprPanic, called at compiler/types/Coercion.hs:2427:9 in ghc:Coercion }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16188> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #16225: GHC HEAD-only Core Lint error (Trans coercion mis-match)
by GHC 04 Mar '19

04 Mar '19

#16225: GHC HEAD-only Core Lint error (Trans coercion mis-match) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.7 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #16188, #16204 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code compiles on GHC 8.0.2 through GHC 8.6.3 with `-dcore- lint`: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind data family Sing :: k -> Type data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type infixr 0 ~> type family Apply (f :: a ~> b) (x :: a) :: b data TyCon1 :: (k1 -> k2) -> (k1 ~> k2) type instance Apply (TyCon1 f) x = f x data SomeApply :: (k ~> Type) -> Type where SomeApply :: Apply f a -> SomeApply f f :: SomeApply (TyCon1 Sing :: k ~> Type) -> SomeApply (TyCon1 Sing :: k ~> Type) f (SomeApply s) = SomeApply s }}} However, it chokes on GHC HEAD: {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 --interactive Bug.hs -dcore-lint GHCi, version 8.7.20190120: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) *** Core Lint errors : in result of Desugar (before optimization) *** <no location info>: warning: In the expression: SomeApply @ k_a1Dz @ (TyCon1 Sing) @ Any (s_a1Bq `cast` (Sub (D:R:ApplyabTyCon1x[0] <k_a1Dz>_N <*>_N <Sing>_N <a_a1DB>_N ; Sym (D:R:ApplyabTyCon1x[0] <k_a1Dz>_N <*>_N <Sing>_N <Any>_N)) :: Apply (TyCon1 Sing) a_a1DB ~R# Apply (TyCon1 Sing) Any)) Trans coercion mis-match: D:R:ApplyabTyCon1x[0] <k_a1Dz>_N <*>_N <Sing>_N <a_a1DB>_N ; Sym (D:R:ApplyabTyCon1x[0] <k_a1Dz>_N <*>_N <Sing>_N <Any>_N) Apply (TyCon1 Sing) a_a1DB Sing a_a1DB Sing Any Apply (TyCon1 Sing) Any *** Offending Program *** <elided> f :: forall k. SomeApply (TyCon1 Sing) -> SomeApply (TyCon1 Sing) [LclIdX] f = \ (@ k_a1Dz) (ds_d1EV :: SomeApply (TyCon1 Sing)) -> case ds_d1EV of wild_00 { SomeApply @ a_a1DB s_a1Bq -> break<0>(s_a1Bq) SomeApply @ k_a1Dz @ (TyCon1 Sing) @ Any (s_a1Bq `cast` (Sub (D:R:ApplyabTyCon1x[0] <k_a1Dz>_N <*>_N <Sing>_N <a_a1DB>_N ; Sym (D:R:ApplyabTyCon1x[0] <k_a1Dz>_N <*>_N <Sing>_N <Any>_N)) :: Apply (TyCon1 Sing) a_a1DB ~R# Apply (TyCon1 Sing) Any)) } }}} Note that if I change the definition of `Sing` to this: {{{#!hs data family Sing (a :: k) }}} Then the error goes away. Also, if I extend `SomeProxy` with an additional `proxy` field: {{{#!hs data SomeApply :: (k ~> Type) -> Type where SomeApply :: proxy a -> Apply f a -> SomeApply f f :: SomeApply (TyCon1 Sing :: k ~> Type) -> SomeApply (TyCon1 Sing :: k ~> Type) f (SomeApply p s) = SomeApply p s }}} Then the error also goes away. Perhaps `a` being ambiguous plays an important role here? Possibly related to #16188 or #16204. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16225> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15849: Error message: "Perhaps you need a let in a do block", when there is no do block.
by GHC 04 Mar '19

04 Mar '19

#15849: Error message: "Perhaps you need a let in a do block", when there is no do block. -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- This code: {{{#!haskell main = return () foo = return () }}} Gives the error message: {{{ parse error on input ‘=’ Perhaps you need a 'let' in a 'do' block? e.g. 'let x = 5' instead of 'x = 5' }}} But this isn't in a do block. It would be awesome if GHC checked whether there's a do block before giving a suggestion that depends on there being a do block. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15849> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15467: unregisterised validation failures
by GHC 04 Mar '19

04 Mar '19

#15467: unregisterised validation failures --------------------------------------+--------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: T7040_ghci | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- The most recent completed run of `validate-x86_64-linux-unreg` on Circle CI (https://circleci.com/gh/ghc/ghc/7733) shows 13 unexpected failures and 1 unexpected pass. **Summary** {{{ Unexpected passes: concurrent/T13615/T13615.run T13615 [unexpected] (ghci) Unexpected failures: codeGen/should_compile/T9329.run T9329 [exit code non-0] (normal) codeGen/should_run/cgrun018.run cgrun018 [exit code non-0] (normal) codeGen/should_run/cgrun018.run cgrun018 [exit code non-0] (g1) codeGen/should_run/cgrun069.run cgrun069 [exit code non-0] (normal) codeGen/should_run/cgrun069.run cgrun069 [exit code non-0] (g1) codeGen/should_run/T9577.run T9577 [bad stdout] (normal) concurrent/should_run/T3429.run T3429 [bad exit code] (debug_numa) driver/T14075/T14075.run T14075 [bad stderr] (normal) rts/T7040_ghci.run T7040_ghci [bad stderr] (ghci) rts/T14702.run T14702 [bad exit code] (threaded1) rts/nursery-chunks1.run nursery-chunks1 [bad stderr] (threaded1) rts/numa001.run numa001 [bad exit code] (debug_numa) ../../libraries/base/tests/T11760.run T11760 [bad exit code] (normal) }}} All failures but `T7040_ghci` happen in the debug validation job too (see #15466). `recomp007` doesn't fail here and `T7040_ghci` "replaces" it. I'm therefore only including the details for `T7040_ghci` here, as you can find out everything about the other faiilures in #15466. --- **T7040_ghci** {{{ Actual stderr output differs from expected: --- /dev/null 2018-08-01 14:20:42.758797000 +0000 +++ ./rts/T7040_ghci.run/T7040_ghci.run.stderr.normalised 2018-08-02 04:15:35.594990695 +0000 @@ -0,0 +1,4 @@ + +T7040_ghci:6:30: + Not in scope: ‘Main.main’ + No module named ‘Main’ is imported. *** unexpected failure for T7040_ghci(ghci) }}} I suspect this is one of those cases where ghci can't load the module because of unboxed sums and what not, I havent' checked yet, but we were seeing that type of error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15467> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11982: Typechecking fails for parallel monad comprehensions with polymorphic let
by GHC 04 Mar '19

04 Mar '19

#11982: Typechecking fails for parallel monad comprehensions with polymorphic let -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE MonadComprehensions, ParallelListComp #-} module Foo where foo xs ys = [ (f y True, f x 'c') | let f _ z = z, x <- xs | y <- ys ] }}} This fails with {{{ Foo.hs:5:52: error: * Cannot instantiate unification variable `t0' with a type involving foralls: forall t2 t3. t3 -> t2 -> t2 GHC doesn't yet support impredicative polymorphism * In a stmt of a monad comprehension: let f _ z = z, x <- xs | y <- ys In the expression: [(f y True, f x 'c') | let f _ z = z, x <- xs | y <- ys] In an equation for `foo': foo xs ys = [(f y True, f x 'c') | let f _ z = z, x <- xs | y <- ys] }}} NB: `ApplicativeDo` has a related problem: the implementation is quite different and has the effect of monomorphising the let-bound variable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11982> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code
by GHC 04 Mar '19

04 Mar '19

#14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (Type checker) | Keywords: deriving | 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: -------------------------------------+------------------------------------- This program //should// compile: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind import Data.Proxy newtype Wat (x :: Proxy (a :: Type)) = MkWat (Maybe a) deriving Eq newtype Glurp a = MkGlurp (Wat ('Proxy :: Proxy a)) deriving Eq }}} After all, it //should// produce this `Eq (Glurp a)` instance, which compiles without issue: {{{#!hs instance Eq a => Eq (Glurp a) where (==) = coerce @(Wat ('Proxy :: Proxy a) -> Wat ('Proxy :: Proxy a) -> Bool) @(Glurp a -> Glurp a -> Bool) (==) }}} But despite my wishful thinking, GHC does not actually do this. In fact, the code that GHC tries to generate for an `Eq (Glurp a)` instance is completely wrong: {{{ $ /opt/ghc/8.2.2/bin/ghci -ddump-deriv Bug.hs GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) ==================== Derived instances ==================== Derived class instances: instance forall a (x :: Data.Proxy.Proxy a). GHC.Classes.Eq a => GHC.Classes.Eq (Bug.Wat x) where (GHC.Classes.==) = GHC.Prim.coerce @(GHC.Base.Maybe a_a2wE -> GHC.Base.Maybe a_a2wE -> GHC.Types.Bool) @(Bug.Wat x_a2wF -> Bug.Wat x_a2wF -> GHC.Types.Bool) (GHC.Classes.==) (GHC.Classes./=) = GHC.Prim.coerce @(GHC.Base.Maybe a_a2wE -> GHC.Base.Maybe a_a2wE -> GHC.Types.Bool) @(Bug.Wat x_a2wF -> Bug.Wat x_a2wF -> GHC.Types.Bool) (GHC.Classes./=) instance GHC.Classes.Eq a => GHC.Classes.Eq (Bug.Glurp a) where (GHC.Classes.==) = GHC.Prim.coerce @(Bug.Wat Data.Proxy.Proxy -> Bug.Wat Data.Proxy.Proxy -> GHC.Types.Bool) @(Bug.Glurp a_a1vT -> Bug.Glurp a_a1vT -> GHC.Types.Bool) (GHC.Classes.==) (GHC.Classes./=) = GHC.Prim.coerce @(Bug.Wat Data.Proxy.Proxy -> Bug.Wat Data.Proxy.Proxy -> GHC.Types.Bool) @(Bug.Glurp a_a1vT -> Bug.Glurp a_a1vT -> GHC.Types.Bool) (GHC.Classes./=) Derived type family instances: Bug.hs:12:12: error: • Couldn't match representation of type ‘a0’ with that of ‘a’ arising from a use of ‘GHC.Prim.coerce’ ‘a’ is a rigid type variable bound by the instance declaration at Bug.hs:12:12-13 • In the expression: GHC.Prim.coerce @(Wat Proxy -> Wat Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (==) In an equation for ‘==’: (==) = GHC.Prim.coerce @(Wat Proxy -> Wat Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (==) When typechecking the code for ‘==’ in a derived instance for ‘Eq (Glurp a)’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘Eq (Glurp a)’ • Relevant bindings include (==) :: Glurp a -> Glurp a -> Bool (bound at Bug.hs:12:12) | 12 | deriving Eq | ^^ Bug.hs:12:12: error: • Could not deduce (Eq a0) arising from a use of ‘==’ from the context: Eq a bound by the instance declaration at Bug.hs:12:12-13 The type variable ‘a0’ is ambiguous These potential instances exist: instance forall k (s :: k). Eq (Proxy s) -- Defined in ‘Data.Proxy’ instance Eq Ordering -- Defined in ‘GHC.Classes’ instance Eq Integer -- Defined in ‘integer-gmp-1.0.1.0:GHC.Integer.Type’ ...plus 25 others ...plus 9 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the third argument of ‘GHC.Prim.coerce’, namely ‘(==)’ In the expression: GHC.Prim.coerce @(Wat Proxy -> Wat Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (==) In an equation for ‘==’: (==) = GHC.Prim.coerce @(Wat Proxy -> Wat Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (==) When typechecking the code for ‘==’ in a derived instance for ‘Eq (Glurp a)’: To see the code I am typechecking, use -ddump-deriv | 12 | deriving Eq | ^^ Bug.hs:12:12: error: • Couldn't match representation of type ‘a1’ with that of ‘a’ arising from a use of ‘GHC.Prim.coerce’ ‘a’ is a rigid type variable bound by the instance declaration at Bug.hs:12:12-13 • In the expression: GHC.Prim.coerce @(Wat Proxy -> Wat Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (/=) In an equation for ‘/=’: (/=) = GHC.Prim.coerce @(Wat Proxy -> Wat Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (/=) When typechecking the code for ‘/=’ in a derived instance for ‘Eq (Glurp a)’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘Eq (Glurp a)’ • Relevant bindings include (/=) :: Glurp a -> Glurp a -> Bool (bound at Bug.hs:12:12) | 12 | deriving Eq | ^^ Bug.hs:12:12: error: • Could not deduce (Eq a1) arising from a use of ‘/=’ from the context: Eq a bound by the instance declaration at Bug.hs:12:12-13 The type variable ‘a1’ is ambiguous These potential instances exist: instance forall k (s :: k). Eq (Proxy s) -- Defined in ‘Data.Proxy’ instance Eq Ordering -- Defined in ‘GHC.Classes’ instance Eq Integer -- Defined in ‘integer-gmp-1.0.1.0:GHC.Integer.Type’ ...plus 25 others ...plus 9 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the third argument of ‘GHC.Prim.coerce’, namely ‘(/=)’ In the expression: GHC.Prim.coerce @(Wat Proxy -> Wat Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (/=) In an equation for ‘/=’: (/=) = GHC.Prim.coerce @(Wat Proxy -> Wat Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (/=) When typechecking the code for ‘/=’ in a derived instance for ‘Eq (Glurp a)’: To see the code I am typechecking, use -ddump-deriv | 12 | deriving Eq | ^^ }}} Yikes. To see what went wrong, let's zoom in a particular part of the `-ddump-deriv` output (cleaned up a bit for presentation purposes): {{{#!hs instance Eq a => Eq (Glurp a) where (==) = coerce @(Wat 'Proxy -> Wat 'Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (==) }}} Notice that it's `Wat 'Proxy`, and not `Wat ('Proxy :: Proxy a)`! And no, that's not just a result of GHC omitting the kind information—you will see the exact same thing if you compile with `-fprint-explicit-kinds`. What's going on here? As it turns out, the types inside of those visible type applications aren't `Type`s, but rather `HsType GhcRn`s (i.e., source syntax). So what is happening is that GHC is literally producing `@(Wat 'Proxy -> Wat 'Proxy -> Bool)` //as source syntax//, not as a `Type`. This means that `'Proxy` has an underspecified kind, resulting in the numerous `The type variable ‘a0’ is ambiguous` errors you see above. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14579> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27

[GHC] #14078: -ddump-json doesn't work well with GHCi
by GHC 04 Mar '19

04 Mar '19

#14078: -ddump-json doesn't work well with GHCi -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.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: -------------------------------------+------------------------------------- Currently, `:set -ddump-json` in `GHCi` causes all errors to be gathered to be written out on exit. `ghci -ddump-json` is even worse, only resulting in a `[]` being output on exit. However, I believe this completely defeats the purpose of this flag in GHCi. I expect `ghci -ddump-json` to work like this: for _each_ evaluation typed at the GHCi prompt, one JSON array is output for all messages this evaluation caused. This proposed behavior is consistent with other flags like `-ddump-simpl`, and will allow tooling to interact with GHCi nicely. Reporting this as a bug because this looks half-supported rather than unsupported, and also because of the different behaviors of `ghci -ddump- json` and `:set -ddump-json`. Sorry if it was not warranted. == Steps to reproduce `cmd>` is the shell prompt. {{{#!hs cmd> ghc --version The Glorious Glasgow Haskell Compilation System, version 8.2.1 cmd> type tmp.hs main = print 2 + 2 cmd> ghci -ddump-json tmp.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( tmp.hs, interpreted ) tmp.hs:1:8: error: ? No instance for (Num (IO ())) arising from a use of ‘+’ ? In the expression: print 2 + 2 In an equation for ‘main’: main = print 2 + 2 | 1 | main = print 2 + 2 | ^^^^^^^^^^^ Failed, 0 modules loaded. Prelude> :q Leaving GHCi. [] cmd> ghci GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Prelude> :set -ddump-json Prelude> :l tmp.hs [1 of 1] Compiling Main ( tmp.hs, interpreted ) tmp.hs:1:8: error: ? No instance for (Num (IO ())) arising from a use of ‘+’ ? In the expression: print 2 + 2 In an equation for ‘main’: main = print 2 + 2 | 1 | main = print 2 + 2 | ^^^^^^^^^^^ Failed, 0 modules loaded. Prelude> :q Leaving GHCi. [ {"span": {"file": "tmp.hs","startLine": 1,"startCol": 8,"endLine": 1,"endCol": 19},"doc": "\u2022 No instance for (Num (IO ())) arising from a use of \u2018+\u2019\n\u2022 In the expression: print 2 + 2\n In an equation for \u2018main\u2019: main = print 2 + 2","severity": "SevError","reason": null}, {"span": null,"doc": "[1 of 1] Compiling Main ( tmp.hs, interpreted )","severity": "SevOutput","reason": null}] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14078> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm
by GHC 04 Mar '19

04 Mar '19

#16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this program: {{{#!hs module Main (main) where import Data.Bits import Data.Word main :: IO () main = print $ toInteger (shiftL 1 hm :: Word64) == toInteger (shiftL 1 hm :: Word64) hm :: Int hm = -1 {-# NOINLINE hm #-} }}} The result of this program depends greatly on what optimization levels are used, and whether `-fllvm` is used: {{{ $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O0 Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... True $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O1 Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... True $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O2 Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... Bug: Bad shift length-1 $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O0 -fllvm Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... True $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O1 -fllvm Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... False $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O2 -fllvm Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... Bug: Bad shift length-1 }}} This program manages to return all of `True`, `False`, and `Bad shift length-1` depending on which flags are used! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16111> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #16104: Plugin name lookup behavior change from GHC 8.4 series
by GHC 04 Mar '19

04 Mar '19

#16104: Plugin name lookup behavior change from GHC 8.4 series -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- I'm trying to port a core plugin to GHC 8.6.3, which was last working fine with GHC 8.4 series. Unfortunately, I'm running into issues. Wondering if pluging programming requirements have changed, or is this a regression in GHC itself. I boiled it down to the following example and would like some guidance on how to make this work: I have the following in file `TestPlugin.hs`: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module TestPlugin (plugin) where import GhcPlugins import Data.Bits plugin :: Plugin plugin = defaultPlugin {installCoreToDos = install} where install _ todos = return (test : todos) test = CoreDoPluginPass "Test" check check :: ModGuts -> CoreM ModGuts check m = do mbN <- thNameToGhcName 'complement case mbN of Just _ -> liftIO $ putStrLn "Found complement!" Nothing -> error "Failed to locate complement" return m }}} And I have a very simple `Test.hs` file: {{{#!hs {-# OPTIONS_GHC -fplugin TestPlugin #-} main :: IO () main = return () }}} With GHC-8.4.2, I have: {{{ $ ghc-8.4.2 --make -package ghc -c TestPlugin.hs [1 of 1] Compiling TestPlugin ( TestPlugin.hs, TestPlugin.o ) $ ghc-8.4.2 -package ghc -c Test.hs Found complement! }}} But with GHC 8.6.3, I get: {{{ $ ghc-8.6.3 --make -package ghc -c TestPlugin.hs [1 of 1] Compiling TestPlugin ( TestPlugin.hs, TestPlugin.o ) $ ghc-8.6.3 -package ghc -c Test.hs ghc: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-apple-darwin): Failed to locate complement }}} The problem goes away if I change `Test.hs` to: {{{#!hs {-# OPTIONS_GHC -fplugin TestPlugin #-} import Data.Bits -- Should not be required in the client code! main :: IO () main = return () }}} That is, if I explicitly import `Data.Bits`. But this is quite undesirable, since `Test.hs` is client code and the users of the plugin have no reason to import all bunch of modules the plugin might need for its own purposes. (In practice, this would require clients to import a whole bunch of irrelevant modules; quite unworkable and not maintainable.) Should I be coding my plugin differently? Or is this a GHC regression? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16104> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #16085: ffi018_ghci fails when unregisterised
by GHC 04 Mar '19

04 Mar '19

#16085: ffi018_ghci fails when unregisterised -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- {{{#!patch --- /dev/null 2018-12-22 16:25:47.047680317 +0000 +++ ffi/should_run/ffi018_ghci.run/ffi018_ghci.run.stderr.normalised 2018-12-22 17:31:34.178826693 +0000 @@ -0,0 +1,4 @@ + +ffi018_ghci:6:30: + Not in scope: ‘Main.main’ + No module named ‘Main’ is imported. }}} I suspect the testsuite driver is hiding the interesting part of the failure. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16085> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12