- ghc-tickets - Haskell.org

[GHC] #13674: GHC doesn't discharge heterogenous equality constraint when it ought to
by GHC 26 May '17

26 May '17

#13674: GHC doesn't discharge heterogenous equality constraint when it ought to -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeInType | 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: -------------------------------------+------------------------------------- Here's some code, reduced from an example in https://github.com/ekmett/constraints/issues/55: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} import Data.Proxy import GHC.Exts (Constraint) import GHC.TypeLits import Unsafe.Coerce (unsafeCoerce) data Dict :: Constraint -> * where Dict :: a => Dict a infixr 9 :- newtype a :- b = Sub (a => Dict b) -- | Given that @a :- b@, derive something that needs a context @b@, using the context @a@ (\\) :: a => (b => r) -> (a :- b) -> r r \\ Sub Dict = r newtype Magic n = Magic (KnownNat n => Dict (KnownNat n)) magic :: forall n m o. (Integer -> Integer -> Integer) -> (KnownNat n, KnownNat m) :- KnownNat o magic f = Sub $ unsafeCoerce (Magic Dict) (natVal (Proxy :: Proxy n) `f` natVal (Proxy :: Proxy m)) type family Lcm :: Nat -> Nat -> Nat where axiom :: forall a b. Dict (a ~ b) axiom = unsafeCoerce (Dict :: Dict (a ~ a)) lcmNat :: forall n m. (KnownNat n, KnownNat m) :- KnownNat (Lcm n m) lcmNat = magic lcm lcmIsIdempotent :: forall n. Dict (n ~ Lcm n n) lcmIsIdempotent = axiom newtype GF (n :: Nat) = GF Integer x :: GF 5 x = GF 3 y :: GF 5 y = GF 4 foo :: (KnownNat m, KnownNat n) => GF m -> GF n -> GF (Lcm m n) foo m@(GF x) n@(GF y) = GF $ (x*y) `mod` (lcm (natVal m) (natVal n)) bar :: (KnownNat m) => GF m -> GF m -> GF m bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) }}} Compiling this (with either GHC 8.0.1, 8.0.2, 8.2.1, or HEAD) gives you a downright puzzling type error: {{{ $ /opt/ghc/head/bin/ghci Bug.hs GHCi, version 8.3.20170509: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:54:21: error: • Couldn't match type ‘m’ with ‘Lcm m m’ ‘m’ is a rigid type variable bound by the type signature for: bar :: forall (m :: Nat). KnownNat m => GF m -> GF m -> GF m at Bug.hs:53:1-44 Expected type: GF m Actual type: GF (Lcm m m) • In the first argument of ‘(-)’, namely ‘foo x y’ In the expression: foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) In an equation for ‘bar’: bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) • Relevant bindings include y :: GF m (bound at Bug.hs:54:17) x :: GF m (bound at Bug.hs:54:6) bar :: GF m -> GF m -> GF m (bound at Bug.hs:54:1) | 54 | bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) | ^^^^^^^ Bug.hs:54:31: error: • Could not deduce: m ~ Lcm m m from the context: m ~ Lcm m m bound by a type expected by the context: m ~ Lcm m m => GF m at Bug.hs:54:31-85 ‘m’ is a rigid type variable bound by the type signature for: bar :: forall (m :: Nat). KnownNat m => GF m -> GF m -> GF m at Bug.hs:53:1-44 Expected type: GF m Actual type: GF (Lcm m m) • In the first argument of ‘(\\)’, namely ‘foo y x’ In the first argument of ‘(\\)’, namely ‘foo y x \\ lcmNat @m @m’ In the second argument of ‘(-)’, namely ‘foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m)’ • Relevant bindings include y :: GF m (bound at Bug.hs:54:17) x :: GF m (bound at Bug.hs:54:6) bar :: GF m -> GF m -> GF m (bound at Bug.hs:54:1) | 54 | bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) | ^^^^^^^ }}} In particular, I'd like to emphasize this part: {{{ • Could not deduce: m ~ Lcm m m from the context: m ~ Lcm m m }}} Wat!? Surely, GHC can deduce `m ~ Lcm m m` from `m ~ Lcm m m`? I decided to flip on `-fprint-explicit-kinds` and see if there was some other issue lurking beneath the surface: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs -fprint-explicit-kinds GHCi, version 8.2.0.20170505: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:54:21: error: • Couldn't match type ‘m’ with ‘Lcm m m’ ‘m’ is a rigid type variable bound by the type signature for: bar :: forall (m :: Nat). KnownNat m => GF m -> GF m -> GF m at Bug.hs:53:1-44 Expected type: GF m Actual type: GF (Lcm m m) • In the first argument of ‘(-)’, namely ‘foo x y’ In the expression: foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) In an equation for ‘bar’: bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) • Relevant bindings include y :: GF m (bound at Bug.hs:54:17) x :: GF m (bound at Bug.hs:54:6) bar :: GF m -> GF m -> GF m (bound at Bug.hs:54:1) | 54 | bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) | ^^^^^^^ Bug.hs:54:31: error: • Could not deduce: (m :: Nat) ~~ (Lcm m m :: Nat) from the context: m ~ Lcm m m bound by a type expected by the context: m ~ Lcm m m => GF m at Bug.hs:54:31-85 ‘m’ is a rigid type variable bound by the type signature for: bar :: forall (m :: Nat). KnownNat m => GF m -> GF m -> GF m at Bug.hs:53:1-44 Expected type: GF m Actual type: GF (Lcm m m) • In the first argument of ‘(\\)’, namely ‘foo y x’ In the first argument of ‘(\\)’, namely ‘foo y x \\ lcmNat @m @m’ In the second argument of ‘(-)’, namely ‘foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m)’ • Relevant bindings include y :: GF m (bound at Bug.hs:54:17) x :: GF m (bound at Bug.hs:54:6) bar :: GF m -> GF m -> GF m (bound at Bug.hs:54:1) | 54 | bar (x :: GF m) y = foo x y - foo y x \\ lcmNat @m @m \\ Sub @() (lcmIsIdempotent @m) | ^^^^^^^ }}} Well, not a whole lot changed. We now have this, slightly more specific error instead: {{{ • Could not deduce: (m :: Nat) ~~ (Lcm m m :: Nat) from the context: m ~ Lcm m m }}} Huh, this is flummoxing. Surely `(m :: Nat) ~~ (Lcm m m :: Nat)` ought to be the same thing as `m ~ Lcm m m`, right? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13674> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #13754: ghc-8.0.2+ rejects more instance declarations
by GHC 26 May '17

26 May '17

#13754: ghc-8.0.2+ rejects more instance declarations -------------------------------------+------------------------------------- Reporter: zilinc | 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: -------------------------------------+------------------------------------- Sorry for the vague title. For a program (sorry again but I failed to shrink it further): {{{ {-# language ExistentialQuantification, KindSignatures, DataKinds, GADTs, UndecidableInstances, AllowAmbiguousTypes #-} class Pretty a where pretty :: a -> String prettyList :: [a] -> String prettyList = concatMap pretty data Def e = forall t. FunDef (Type t) (e t) data Nat = Z | S Nat data F (t :: Nat) where FZ :: F (S Z) FS :: F n -> F (S n) data Type (t :: Nat) = TVar (F t) data Expr (t :: Nat) e = Fun (Type t) | App (e t) (e t) data TE t = TE (Type t) (Expr t TE) -- all methods left undefined, as they're insignificant instance Pretty t => Pretty [t] where pretty = undefined instance (Pretty (e t)) => Pretty (Def e) where pretty (FunDef t e) = undefined instance Pretty (Type t) where pretty (TVar t) = undefined instance Pretty (e t) => Pretty (Expr t e) where pretty (Fun t) = undefined pretty (App e1 e2) = undefined instance Pretty (TE t) where pretty (TE t e) = undefined }}} ghc-8.0.1 is happy with it, whereas later versions (tested with 8.0.2 and 8.2.1-rc2) reject it. The error msg is: {{{ GHCInstance1.hs:27:10: error: • Could not deduce (Pretty (e t0)) arising from a use of ‘Main.$dmprettyList’ from the context: Pretty (e t) bound by the instance declaration at GHCInstance1.hs:27:10-41 The type variable ‘t0’ is ambiguous Relevant bindings include prettyList :: [Def e] -> String (bound at GHCInstance1.hs:27:10) • In the expression: Main.$dmprettyList @Def e In an equation for ‘prettyList’: prettyList = Main.$dmprettyList @Def e In the instance declaration for ‘Pretty (Def e)’ }}} If I comment out the `prettyList` method from the class definition, then all happy. I'm not sure if it's a bug in 8.0.1 or a regression (and hard to reason about the behaviours). If it was the later, how should I migrate from 8.0.1? The `Pretty` class is a library (e.g. ansi-wl-pprint) so no way I can change it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13754> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13729: ghc does not pick up TH changes across package boundaries
by GHC 25 May '17

25 May '17

#13729: ghc does not pick up TH changes across package boundaries -------------------------------------+------------------------------------- Reporter: Feuerbach | 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: -------------------------------------+------------------------------------- I have the following three modules: {{{#!hs module Types where data Foo = Bar }}} {{{#!hs {-# LANGUAGE TemplateHaskell #-} module TH where import Language.Haskell.TH import Language.Haskell.TH.Syntax import Types th_string = lift . show =<< reify ''Foo }}} {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Main where import TH main = putStrLn $(th_string) }}} The goal is to make Main recompile if the definition of Types.Foo changes. If I simply put the three files in the same directory and compile with ghc, it works. However, if I put Types and TH in package A and Main in package B, then ghc doesn't recompile B.Main if I change the definition of A.Types.Foo and reinstall the package A. I tried this with both stack and cabal-install. In both cases I compiled B.Main directly with ghc, so it's not Cabal that's hiding the changes. If I pass -fforce-recomp to ghc, Main recompiles as expected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13729> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13718: diagnostic colors: differentiate between message head and message body
by GHC 25 May '17

25 May '17

#13718: diagnostic colors: differentiate between message head and message body -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #13444 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When a diagnostic message is printed, currently the whole message is colored by the "message" color (bold by default). I'd find it useful if the message body and the header could be differentiated (I do like the idea that the header stands out). Motivation: Consider the following error message, {{{ GHCi, version 8.2.0.20170508: http://www.haskell.org/ghc/ :? for help Prelude> () () <interactive>:1:1: error: • Couldn't match expected type ‘() -> t’ with actual type ‘()’ • The function ‘()’ is applied to one argument, but its type ‘()’ has none In the expression: () () In an equation for ‘it’: it = () () • Relevant bindings include it :: t (bound at <interactive>:1:1) }}} which by default is all bold, with the {{{error:}}} part in red. I want the message body to use normal text. Thanks to #13444 I can achieve that by setting {{{GHC_COLORS="message=0"}}}. However, that setting also affects the initial {{{<interactive>:1:1}}} part of the headline, which now looks odd because normal and bold text are mixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13718> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13749: Panic (initTc: unresolved constraints) on some bad code
by GHC 23 May '17

23 May '17

#13749: Panic (initTc: unresolved constraints) on some bad code -------------------------------------+------------------------------------- Reporter: uranium | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was just refactoring some code, and partway through, before it was all compiling, I hit the below error. The code's probably just terrible in an interestingly new way; I'm pretty inexperienced at Haskell. I'll attach the file. Prelude> :r [1 of 1] Compiling Main ( /home/uranium/projects/server/src/Main.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] get_aGsK :: t_aGsJ[tau:1] (CHoleCan: get) [W] execState_aGsX :: t_aGsW[tau:1] (CHoleCan: execState) [W] get_aGvL :: t_aGvK[tau:1] (CHoleCan: get) [W] lift_aGvU :: t_aGvT[tau:1] (CHoleCan: lift) [W] put_aGw3 :: t_aGw2[tau:1] (CHoleCan: put) [W] cellType_aGwy :: t_aGwx[tau:1] (CHoleCan: cellType) [W] insts_aGwB :: t_aGwA[tau:1] (CHoleCan: insts) [W] ports_aGwE :: t_aGwD[tau:1] (CHoleCan: ports) [W] conns_aGwH :: t_aGwG[tau:1] (CHoleCan: conns) [W] annos_aGwK :: t_aGwJ[tau:1] (CHoleCan: annos) [W] comms_aGwN :: t_aGwM[tau:1] (CHoleCan: comms)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13749> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty`
by GHC 23 May '17

23 May '17

#10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #1062, #1176, Differential Revisions: | #7666 -------------------------------------+------------------------------------- GHC has an internal copy of `pretty` in `compiler/utils/Pretty.hs`. Todo: * refactor GHC's copy to make it as similar as possible to `pretty`, without making any real code changes. * apply the bug fixes that `pretty` received to GHC's copy, making sure not to pick up any possible new bugs in the process. According to (1): "There is one situation where the laws for pretty are ambiguous and leave room for choice. GHC decided one way and pretty the other." * Find which law that is, and document the differences. This hopefully allows us to close the following tickets for free: #1062, #1176 and #7666, maybe more. Ideally we could remove GHC's copy altogether, but we're not there yet. GHC's copy uses FastString, which is supposedly needed for performance, whereas pretty uses `String`. (1) https://github.com/haskell/pretty/issues/1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10735> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #13727: `-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules
by GHC 23 May '17

23 May '17

#13727: `-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `-Wmissing-home-modules` feature was implemented in order to be used by Cabal (see also #13129), however it turns out that it currently has a minor bug which makes it much less useful for `cabal` as we can't enable it for executables this way, as Cabal needs to provide the path to the Main module directly. Consider the following two files: - `src-lib/M1.hs` {{{#!hs module M1 where }}} - `src-exe/Main.hs` {{{#!hs import M1 main = return () }}} And now consider the following inconsistent results: Expected good behaviour: {{{ ghc-8.2.1 -fforce-recomp -Wmissing-home-modules -isrc-lib -isrc-exe Main <no location info>: warning: [-Wmissing-home-modules] Modules are not listed in command line: M1 [1 of 2] Compiling M1 ( src-lib/M1.hs, src-lib/M1.o ) [2 of 2] Compiling Main ( src-exe/Main.hs, src-exe/Main.o ) Linking src-exe/Main ... }}} {{{ ghc-8.2.1 -fforce-recomp -Wmissing-home-modules -isrc-lib -isrc-exe M1 Main [1 of 2] Compiling M1 ( src-lib/M1.hs, src-lib/M1.o ) [2 of 2] Compiling Main ( src-exe/Main.hs, src-exe/Main.o ) Linking src-exe/Main ... }}} Unexpected bad behaviour: {{{ ghc-8.2.1 -fforce-recomp -Wmissing-home-modules src-lib/M1.hs src- exe/Main.hs <no location info>: warning: [-Wmissing-home-modules] Modules are not listed in command line: M1 Main [1 of 2] Compiling M1 ( src-lib/M1.hs, src-lib/M1.o ) [2 of 2] Compiling Main ( src-exe/Main.hs, src-exe/Main.o ) Linking src-exe/Main ... }}} {{{ ghc-8.2.1 -fforce-recomp -Wmissing-home-modules -isrc-lib M1 src-exe/Main <no location info>: warning: [-Wmissing-home-modules] Modules are not listed in command line: Main [1 of 2] Compiling M1 ( src-lib/M1.hs, src-lib/M1.o ) [2 of 2] Compiling Main ( src-exe/Main.hs, src-exe/Main.o ) Linking src-exe/Main ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13727> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9287: changed dependency generation
by GHC 23 May '17

23 May '17

#9287: changed dependency generation ------------------------------------+-------------------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- "ghc -M" for ghc-7.8.x changed in that an error occurs: {{{ You must specify at least one -dep-suffix }}} By chance (#8746) I found that {{{ ghc -M -dep-suffix "" B.hs }}} works, but only for the new ghc-7.8.x. For module B importing module A the following dependencies are generated: {{{ # DO NOT DELETE: Beginning of Haskell dependencies A.o : A.hs B.o : B.hs B.o : A.hi # DO NOT DELETE: End of Haskell dependencies }}} The same command used with ghc-7.6.x produces wrong dependencies: {{{ # DO NOT DELETE: Beginning of Haskell dependencies A.o A._o : A.hs B.o B._o : B.hs B.o : A.hi B._o : A._hi # DO NOT DELETE: End of Haskell dependencies }}} Obviously, only for dynamic linking a dep-suffix should be needed. However for ghc-7.6. this must be "dyn" and for ghc-7.8.x this must "dyn_" plus the empty suffix! {{{ ghc-7.6.3 -M -dep-suffix dyn B.hs ghc-7.8.2 -M -dep-suffix dyn_ -dep-suffix "" B.hs }}} Both calls produce: {{{ # DO NOT DELETE: Beginning of Haskell dependencies A.o A.dyn_o : A.hs B.o B.dyn_o : B.hs B.o : A.hi B.dyn_o : A.dyn_hi # DO NOT DELETE: End of Haskell dependencies }}} The changed behavior is not documented in http://www.haskell.org/ghc/docs/7.8.2/html/users_guide/separate- compilation.html#makefile-dependencies The (accidental?) change should also be documented in the release notes! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9287> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13625: GHC internal error: ‘Y’ is not in scope during type checking, but it passed the renamer
by GHC 23 May '17

23 May '17

#13625: GHC internal error: ‘Y’ is not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: mpickering | 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: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE TypeInType #-} data X :: Y where Y :: X }}} The error message is: {{{ Bug.hs:2:11: error: … • GHC internal error: ‘Y’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [r1cR :-> APromotionErr TyConPE] • In the kind ‘Y’ }}} Originally reported by @mietek in #11821 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13625> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13743: Colourise command output
by GHC 23 May '17

23 May '17

#13743: Colourise command output -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- Our error messages are now colourful (#10073), can we do the same for the output of commands like `:info`? `:info` has gotten bloated (I also think the context / instance head should be swapped, but that's another story), adding colour would make it easier to read {{{#!html <pre> >>> :i Int data Int = I# E.Int# -- Defined in ‘GHC.Types’ instance Eq Int -- Defined in ‘GHC.Classes’ instance Ord Int -- Defined in ‘GHC.Classes’ instance Show Int -- Defined in ‘GHC.Show’ instance Read Int -- Defined in ‘GHC.Read’ instance Enum Int -- Defined in ‘GHC.Enum’ instance Num Int -- Defined in ‘GHC.Num’ instance Real Int -- Defined in ‘GHC.Real’ instance [safe] NFData Int -- Defined in ‘Control.DeepSeq’ instance Data Int -- Defined in ‘Data.Data’ instance Bounded Int -- Defined in ‘GHC.Enum’ instance O.Outputable Int -- Defined in ‘Outputable’ instance [safe] PrintfArg Int -- Defined in ‘Text.Printf’ instance Integral Int -- Defined in ‘GHC.Real’ </pre> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13743> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5