December 2018 - ghc-tickets

[GHC] #15863: Splcing a type class method selects the wrong instance
by GHC 04 Mar '19

04 Mar '19

#15863: Splcing a type class method selects the wrong instance -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Consider these 4 modules as concocted by Csongor. The wrong instance is selected when you splice in `B.me` into `D`. https://gist.github.com/mpickering/959a95525647802414ab50e8e6ed490c {{{ module A where class C a where foo :: a -> String instance C Int where foo _ = "int" }}} {{{ {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE NoMonomorphismRestriction #-} module B where import A import Language.Haskell.TH instance C a => C [a] where foo _ = "list" me :: Q (TExp ([Int] -> String)) me = [|| foo ||] }}} {{{ {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE NoMonomorphismRestriction #-} module C where import A import Language.Haskell.TH instance {-# OVERLAPPING #-} C [Int] where foo _ = "list2" }}} {{{ {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE NoMonomorphismRestriction #-} module D where import A import B import C main2 = $$(me) [1 :: Int] }}} {{{ >>> main2 "list2" }}} In `B`, `B.me` is created by quoting `foo`. `B.me :: Q (TExp ([Int] -> String))` so in order to type check this quote we need to solve the instance `C [Int]` which we should do by using the instance defined in `B` (and `A`). In module `C` we define a different overlapping instance (note that this could be in a completely different library not under our control). When we then splice `B.me` into `D`, the instance from `C` is used and can be witnessed by printing `main2` which shows `"list2"` rather than `"list"` as expected. This is a symptom of the fact that the renamed rather than the typechecked AST is serialised I think. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15863> 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

[GHC] #16086: Compile countLeadingZeros to lzcnt if -mbmi2 is set
by GHC 04 Mar '19

04 Mar '19

#16086: Compile countLeadingZeros to lzcnt if -mbmi2 is set -------------------------------------+------------------------------------- Reporter: ethercrow | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.6.3 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I started implementing this in https://gitlab.haskell.org/ghc/ghc/merge_requests/27 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16086> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4