- ghc-tickets - Haskell.org

[GHC] #13706: ghci messages like "Ok, modules loaded: ..." are impractical for large sets of modules
by GHC 18 Feb '19

18 Feb '19

#13706: ghci messages like "Ok, modules loaded: ..." are impractical for large sets of modules -------------------------------------+------------------------------------- Reporter: j.waldmann | 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: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Ghci (in the default config) wants to show me all the modules that are currently loaded. If I have a great many of these (think: hundreds) then this is impractical, because I have to scroll back to see what actually interests me (output of last command). I can change the prompt (`:set prompt "> "`), but I don't see how to switch off the display of all module names in `:r` command. I have to scroll back (several screenfulls) to even find out whether the reload was successful, since the status (OK/Failed) is at the very beginning - and the reason for the Failure is before that. Cf. https://mail.haskell.org/pipermail/haskell-cafe/2017-May/126983.html (but there was no reaction) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13706> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2]
by GHC 18 Feb '19

18 Feb '19

#14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies, | PartialTypeSignatures | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #13877 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (Originally spun off from #13877.) The following program gives a somewhat decent error message in GHC 8.0.1: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind data family Sing (a :: k) data WeirdList :: Type -> Type where WeirdNil :: WeirdList a WeirdCons :: a -> WeirdList (WeirdList a) -> WeirdList a data instance Sing (z :: WeirdList a) where SWeirdNil :: Sing WeirdNil SWeirdCons :: Sing w -> Sing wws -> Sing (WeirdCons w wws) elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl elimWeirdList SWeirdNil pWeirdNil _ = pWeirdNil elimWeirdList (SWeirdCons (x :: Sing (x :: z)) (xs :: Sing (xs :: WeirdList (WeirdList z)))) pWeirdNil pWeirdCons = pWeirdCons @z @x @xs x xs (elimWeirdList @(WeirdList z) @xs @p xs pWeirdNil pWeirdCons) }}} {{{ $ /opt/ghc/8.0.1/bin/ghci Foo.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Foo.hs, interpreted ) Foo.hs:34:8: error: • Cannot apply expression of type ‘Sing wl -> (forall y. p x0 t3 'WeirdNil) -> (forall z (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p (WeirdList z) t2 xs -> p z t1 ('WeirdCons x xs)) -> p a t0 wl’ to a visible type argument ‘WeirdList z’ • In the sixth argument of ‘pWeirdCons’, namely ‘(elimWeirdList @(WeirdList z) @xs @p xs pWeirdNil pWeirdCons)’ In the expression: pWeirdCons @z @x @xs x xs (elimWeirdList @(WeirdList z) @xs @p xs pWeirdNil pWeirdCons) In an equation for ‘elimWeirdList’: elimWeirdList (SWeirdCons (x :: Sing (x :: z)) (xs :: Sing (xs :: WeirdList (WeirdList z)))) pWeirdNil pWeirdCons = pWeirdCons @z @x @xs x xs (elimWeirdList @(WeirdList z) @xs @p xs pWeirdNil pWeirdCons) }}} But in GHC 8.0.2, 8.2.1, and HEAD, it panics to varying degrees: {{{ $ /opt/ghc/8.0.2/bin/ghci Foo.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Foo.hs, interpreted ) Foo.hs:24:41: error: • Found type wildcard ‘_’ standing for ‘t0’ Where: ‘t0’ is an ambiguous type variable ‘x0’ is an ambiguous type variable To use the inferred type, enable PartialTypeSignatures • In the type signature: elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl • Relevant bindings include elimWeirdList :: Sing wl -> (forall y. p x0 t0 'WeirdNil) -> (forall z (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p (WeirdList z) t1 xs -> p z t2 ('WeirdCons x xs)) -> p a t3 wl (bound at Foo.hs:29:1) Foo.hs:26:44: error:ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): No skolem info: z_a13X[sk] }}} {{{ $ /opt/ghc/8.2.1/bin/ghci Foo.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Foo.hs, interpreted ) Foo.hs:21:18: error: • The kind of variable ‘wl1’, namely ‘WeirdList a1’, depends on variable ‘a1’ from an inner scope Perhaps bind ‘wl1’ sometime after binding ‘a1’ • In the type signature: elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl | 21 | elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... Foo.hs:24:41: error: • Found type wildcard ‘_’ standing for ‘w0’ Where: ‘w0’ is an ambiguous type variable ‘x0’ is an ambiguous type variable To use the inferred type, enable PartialTypeSignatures • In the type signature: elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl | 24 | -> (forall (y :: Type). p _ WeirdNil) | ^ Foo.hs:26:44: error:ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): No skolem info: z_a1sY[sk:2] 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/typecheck/TcErrors.hs:2653:5 in ghc:TcErrors }}} (The error messages from HEAD, at commit 791947db6db32ef7d4772a821a0823e558e3c05b, are the same as in GHC 8.2.1.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14040> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #16312: Optimization + adding an INLINE pragma triggers Core Lint error (Type of case alternatives not the same as the annotation on case)
by GHC 18 Feb '19

18 Feb '19

#16312: Optimization + adding an INLINE pragma triggers Core Lint error (Type of case alternatives not the same as the annotation on case) -------------------------------------+------------------------------------- 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: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's a seemingly innocuous program, minimized from the `kan-extensions` library: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} module Bug where newtype Curried g h a = Curried { runCurried :: forall r. g (a -> r) -> h r } instance Functor g => Functor (Curried g h) where fmap f (Curried g) = Curried (g . fmap (.f)) instance (Functor g, g ~ h) => Applicative (Curried g h) where pure a = Curried (fmap ($a)) Curried mf <*> Curried ma = Curried (ma . mf . fmap (.)) {-# INLINE (<*>) #-} -- The Core Lint error goes away if you remove this INLINE pragma }}} However, it triggers a Core Lint error on GHC 8.2.2 through HEAD if you compile it with `-O` and `-dcore-lint`: {{{ $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -dcore-lint Bug.hs -O [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint errors : in result of Simplifier *** <no location info>: warning: In the expression: (case heq_sel @ (* -> *) @ (* -> *) @ h_a1eC @ h_a1eC ($d~_a1eE `cast` (((~) <* -> *>_N co_a1hx <h_a1eC>_N)_R ; N:~[0] <* -> *>_N <h_a1eC>_N <h_a1eC>_N :: (g_a1eB ~ h_a1eC) ~R# (h_a1eC ~~ h_a1eC))) of co_X1ij { __DEFAULT -> (\ (@ a_a1fg) (@ b_a1fh) (ds_d1yw :: Curried h_a1eC h_a1eC (a_a1fg -> b_a1fh)) (ds_d1yx :: Curried h_a1eC h_a1eC a_a1fg) (@ r_a1fn) -> let { g_X1zi :: h_a1eC (b_a1fh -> r_a1fn) -> h_a1eC ((a_a1fg -> b_a1fh) -> a_a1fg -> r_a1fn) [LclId, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 30 0}] g_X1zi = fmap @ h_a1eC ($dFunctor_a1eD `cast` ((Functor co_a1hx)_R :: Functor g_a1eB ~R# Functor h_a1eC)) @ (b_a1fh -> r_a1fn) @ ((a_a1fg -> b_a1fh) -> a_a1fg -> r_a1fn) (. @ b_a1fh @ r_a1fn @ a_a1fg) } in \ (x_X1zn :: h_a1eC (b_a1fh -> r_a1fn)) -> (ds_d1yx `cast` (N:Curried[0] <h_a1eC>_R <h_a1eC>_R <a_a1fg>_N :: Curried h_a1eC h_a1eC a_a1fg ~R# (forall r. h_a1eC (a_a1fg -> r) -> h_a1eC r))) @ r_a1fn ((ds_d1yw `cast` (N:Curried[0] <h_a1eC>_R <h_a1eC>_R <a_a1fg -> b_a1fh>_N :: Curried h_a1eC h_a1eC (a_a1fg -> b_a1fh) ~R# (forall r. h_a1eC ((a_a1fg -> b_a1fh) -> r) -> h_a1eC r))) @ (a_a1fg -> r_a1fn) (g_X1zi x_X1zn))) `cast` (forall (a :: <*>_N) (b :: <*>_N). <Curried h_a1eC h_a1eC (a -> b)>_R ->_R <Curried h_a1eC h_a1eC a>_R ->_R Sym (N:Curried[0] <h_a1eC>_R <h_a1eC>_R <b>_N) :: (forall a b. Curried h_a1eC h_a1eC (a -> b) -> Curried h_a1eC h_a1eC a -> forall r. h_a1eC (b -> r) -> h_a1eC r) ~R# (forall a b. Curried h_a1eC h_a1eC (a -> b) -> Curried h_a1eC h_a1eC a -> Curried h_a1eC h_a1eC b)) }) @ b_a1gi @ b_a1gi ((<$ @ (Curried g_a1eB h_a1eC) ($dFunctor_s1zH `cast` ((Functor (Curried (Sym co_a1hx) <h_a1eC>_N)_N)_R :: Functor (Curried h_a1eC h_a1eC) ~R# Functor (Curried g_a1eB h_a1eC))) @ (b_a1gi -> b_a1gi) @ a_a1gh (breakpoint @ b_a1gi) a1_a1z1) `cast` (Sym (Curried (Sub (Sym co_a1hx)) <h_a1eC>_R <b_a1gi -> b_a1gi>_N)_R :: Curried g_a1eB h_a1eC (b_a1gi -> b_a1gi) ~R# Curried h_a1eC h_a1eC (b_a1gi -> b_a1gi))) (a2_a1z2 `cast` (Sym (Curried (Sub (Sym co_a1hx)) <h_a1eC>_R <b_a1gi>_N)_R :: Curried g_a1eB h_a1eC b_a1gi ~R# Curried h_a1eC h_a1eC b_a1gi)) Type of case alternatives not the same as the annotation on case: Actual type: forall a b. Curried h_a1eC h_a1eC (a -> b) -> Curried h_a1eC h_a1eC a -> Curried h_a1eC h_a1eC b Annotation on case: forall a b. Curried g_a1eB h_a1eC (a -> b) -> Curried g_a1eB h_a1eC a -> Curried g_a1eB h_a1eC b }}} The size of the `-dcore-lint` output is enormous, so I'll post it separately as an attachment. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16312> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16243: Improve fregs-graph.
by GHC 18 Feb '19

18 Feb '19

#16243: Improve fregs-graph. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (CodeGen) | Keywords: fregs-graph | 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 creating this as a way to keep track of shortcomings of the current implementation. Some of these are directly taken from TODOS, other are my own opinions. = Things that could be looked at. == Compress spill slots. Currently we assign each vreg a fixed spill slot. This is terrible for cache performance. It's possible to end up with sequences like this: {{{#!asm block_ca01_info: _ca01: movq 16(%rbp),%r14 movq 24(%rbp),%rax movq %rax,144(%rsp) movq 32(%rbp),%rsi movq 40(%rbp),%rdi movq 64(%rbp),%rbx movq 56(%rbp),%rax movq %rax,208(%rsp) movq 48(%rbp),%rax movq %rax,168(%rsp) movq 8(%rbp),%rax movq %rax,216(%rsp) addq $8,%rbp }}} Which splits spill slots over multiple cache lines increasing cache pressure. Things possibly worth trying: * Assign spill slots in the order they appear - hopefully reducing the average spread within code blocks. * Dynamically assign vregs to spill slots. For the later if we have large independent subgraphs we will sometimes get away with using far fewer slots. The reason simply being that non overlapping vregs can share spill slots. Doing this in an efficient manner however isn't easy. == We sometimes load + spill vregs when we could use memory addressing. One example I've seen a few times in nofib is this: {{{ movq 208(%rsp),%rax incq %rax movq %rax,208(%rsp) }}} Which we should replace with a single `inc` operating on memory. == Lift the stack size limit. There is already a patch [https://gitlab.haskell.org/ghc/ghc/merge_requests/219 in flight]. == Revisit spill costs. Currently the allocator always spills the longest live range. Which often works but is certainly not a great metric. Ideas: === Consider loop membership. At least for x86/64 this would be easy to achieve on basic block granularity using the CFG that is also used for block layout. === Revisit chaitins cost model. There have been major changes to cpus (amd64 becoming the norm) and the backend so at a minimum this cost model should be reevaluated. == Try splitting long live ranges instead of simply spilling the complete live range. After all long live ranges were the original reason to switch to a life range only based cost heuristic. == Use a different spill algorithm altogether. Maybe Chows live range splitting based approach would be an option. See "The priority based coloring approach to register allocation" for details. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16243> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16333: Implement Loop-invariant code motion / Hoisting for Cmm
by GHC 18 Feb '19

18 Feb '19

#16333: Implement Loop-invariant code motion / Hoisting for Cmm -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | 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: #12808 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently we don't but we should. An example from nofib: This is the innermost loop of fannkuch-redux. {{{ #!C ca12: _s9D0::I64 = %MO_UU_Conv_W8_W64(I8[_s9zN::I64]); if (_s9D0::I64 != 0) goto ca1f; else goto ca1i; ca1f: I64[Sp - 16] = ca1d; R3 = _s9zN::I64 + _s9D0::I64; R2 = _s9zN::I64; I64[Sp - 8] = _s9CV::I64; I64[Sp] = _s9Cd::I64; I64[Sp + 40] = _s9Cc::I64; I64[Sp + 48] = _s9Cb::I64; I64[Sp + 56] = _s9zN::I64; Sp = Sp - 16; call $wflopp_r9x0_info(R3, R2) returns to ca1d, args: 8, res: 8, upd: 8; ca1d: Sp = Sp + 16; _s9CV::I64 = I64[Sp - 8] + 1; _s9Cd::I64 = I64[Sp + 0]; 16 _s9z5::I64 = I64[Sp + 8]; //24 _s9zv::I64 = I64[Sp + 16]; 32 _s9zx::I64 = I64[Sp + 24]; 40 _s9zz::I64 = I64[Sp + 32]; 48 _s9Cc::I64 = I64[Sp + 40]; 56 _s9Cb::I64 = I64[Sp + 48]; 64 _s9zN::I64 = I64[Sp + 56]; 72 goto ca12; }}} We should try to move the loads NOT used in the loop out of the loop at least. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16333> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space
by GHC 18 Feb '19

18 Feb '19

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving- | perf, Generics, Deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: #13059 | Differential Rev(s): Phab:D2304 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: deriving-perf, Generics => deriving-perf, Generics, Deriving Comment: Ben, when we emerge from the CI swamp, this ticket looks like one of several GHC-perf tickets that deserve renewed attention. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:53> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16314: Improve confusing error message with MINIMAL pragma
by GHC 18 Feb '19

18 Feb '19

#16314: Improve confusing error message with MINIMAL pragma -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: feature | Status: new request | 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 got bitten by this recently, and while I can see GHC's reasoning, I wish it told me something different and more useful. {{{#!hs class X a where foo :: a {-# MINIMAL foo #-} foo = undefined instance X Int }}} For this program, ghc says: {{{ GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( a.hs, interpreted ) a.hs:7:10: warning: [-Wmissing-methods] • No explicit implementation for ‘foo’ • In the instance declaration for ‘X Int’ | 7 | instance X Int | ^^^^^ }}} This is arguably "correct", since I made `foo` part of `MINIMAL`; but it's very confusing, because I know I added a default definition. I wish GHC instead said something like: {{{ You made `foo` MINIMAL, but also gave an explicit definition for it. }}} I can see the logic behind the current error message, but it was rather confusing. The background is that my class had many other methods and a `MINIMAL` pragma. Much later I realized I could give a default definition of one of those methods but I forgot to remove it from the `MINIMAL` list. So, I had to puzzle a while at the error messages that were coming from far away modules that had nothing to do with the class definition itself. This is not a showstopper by any means, but unless there are good reasons to do otherwise, it would be nice to get a warning right where the class is defined, as opposed to where it is instantiated. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16314> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12612: Allow kinds of associated types to depend on earlier associated types
by GHC 18 Feb '19

18 Feb '19

#12612: Allow kinds of associated types to depend on earlier associated types -------------------------------------+------------------------------------- Reporter: davemenendez | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC rejects the following code: {{{#!hs class C t where type K t :: Type type T t :: K t -> Type m :: t -> T t a }}} with this error message {{{ • Type constructor ‘K’ cannot be used here (it is defined and used in the same recursive group) • In the kind ‘K t -> Type’ }}} See [https://mail.haskell.org/pipermail/glasgow-haskell- users/2016-September/026402.html e-mail discussion]. This is connected to #12088, at least as far as defining instances of C. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12612> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12218: Implement -fexternal-interpreter via static linking
by GHC 18 Feb '19

18 Feb '19

#12218: Implement -fexternal-interpreter via static linking -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- An interesting idea from @hvr. When using `-fexternal-interpreter`, we can statically link the required packages and object files into a new iconv binary, and use that as our external interpreter. This would mean we could support TH and even limited GHCi without needing a dynamic linker of any kind, which is extremely cool. Apparently this would be useful for AIX where doing dynamic linking is hard. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12218> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16206: Run Haddock's test suite in CI
by GHC 18 Feb '19

18 Feb '19

#16206: Run Haddock's test suite in CI -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | 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: -------------------------------------+------------------------------------- Many changes in GHC affect Haddock's output, breaking its test suite. Recent examples are [https://gitlab.haskell.org/ghc/ghc/commit/53874834b779ad0dfbcde6650069c3792… 5387483] and [https://gitlab.haskell.org/ghc/ghc/commit/7cba71fc25af8287db61f6f6aa80d45ce… 7cba71f]. If cases like these were caught during CI, they could be fixed immediately, avoiding follow-up cleanup work by the Haddock maintainer. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16206> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4