December 2018 - ghc-tickets

[GHC] #15999: Stabilise nofib runtime measurements
by GHC 09 Jan '19

09 Jan '19

#15999: Stabilise nofib runtime measurements -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib | Version: 8.6.2 benchmark suite | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #5793 #9476 | #15333 #15357 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With Phab:D4989 (cf. #15357) having hit `nofib` master, there are still many benchmarks that are unstable. I identified three causes for unstability in https://ghc.haskell.org/trac/ghc/ticket/5793#comment:38. With system overhead mostly out of the equation, there are still two related tasks left: 1. Identify benchmarks with GC wibbles. Plan: Look at counted instructions while varying heap size with just one generation. A wibbling benchmark should have quite diverse sampled maximum residency (as opposed to a microbenchmark, which should have quite stable instruction count). Then fix these by iterating `main` 'often enough'. Maybe look at total bytes allocated for that, we want this to be monotonically declining as the initial heap size grows. 2. Now, all benchmarks should have stable instruction count. If not, maybe there's another class of benchmarks I didn't identify yet in #5793. Of these benchmarks, there are a few, like `real/eff/CS`, that still have highly unstable runtimes. Fix these 'microbenchmarks' by hiding them behind a flag. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15999> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15357: Make nofib suitable for runtime measurements.
by GHC 09 Jan '19

09 Jan '19

#15357: Make nofib suitable for runtime measurements. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: NoFib | Version: 8.4.3 benchmark suite | 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 many benchmarks in a default nofib run have runtimes so low that they become meaningless. This comes with a bunch of issues: * It takes up build/runtime while not actually improving the accuracy of runtime measurements. * It skews results as the jump from 1ms to 2ms registers as a 200% change. * It can hide regression which fall outside of the measured granularity. * Higher number of runs per benchmark spend far too much time on the few slower benchmarks. At the extreme end there are 9 benchmarks with runtimes shorter than the granularity of 1ms. For some benchmarks changing this might be as easy as increasing the number of runs/iterations. For others changing problem sizes is not as easy since they process more complex input data. Below are the runtimes of a recent default nofib run. ||= benchmark =|| Time (ms) || || ansi || 0 || || awards || 0 || || banner || 0 || || calendar || 0 || || expert || 0 || || gen_regexps || 0 || || grep || 0 || || pretty || 0 || || scc || 0 || || cse || 1 || || eliza || 1 || || lift || 1 || || mkhprog || 1 || || prolog || 1 || || sorting || 1 || || veritas || 1 || || knights || 2 || || minimax || 2 || || x2n1 || 2 || || mandel2 || 3 || || parstof || 3 || || fluid || 4 || || pic || 4 || || boyer2 || 5 || || bspt || 5 || || cryptarithm2 || 5 || || fish || 6 || || gg || 6 || || reptile || 6 || || symalg || 6 || || tak || 6 || || VSD || 7 || || rfib || 7 || || queens || 9 || || rewrite || 9 || || sched || 11 || || fem || 12 || || fibheaps || 13 || || parser || 14 || || rsa || 14 || || genfft || 15 || || clausify || ansi || 0 || || awards || 0 || || banner || 0 || || calendar || 0 || || expert || 0 || || gen_regexps || 0 || || grep || 0 || || pretty || 0 || || scc || 0 || || cse || 1 || || eliza || 1 || || lift || 1 || || mkhprog || 1 || || prolog || 1 || || sorting || 1 || || veritas || 1 || || knights || 2 || || minimax || 2 || || x2n1 || 2 || || mandel2 || 3 || || parstof || 3 || || fluid || 4 || || pic || 4 || || boyer2 || 5 || || bspt || 5 || || cryptarithm2 || 5 || || fish || 6 || || gg || 6 || || reptile || 6 || || symalg || 6 || || tak || 6 || || VSD || 7 || || rfib || 7 || || queens || 9 || || rewrite || 9 || || sched || 11 || || fem || 12 || || fibheaps || 13 || || parser || 14 || || rsa || 14 || || genfft || 15 || || clausify || 17 || || gamteb || 17 || || fft || 18 || || boyer || 20 || || gcd || 20 || || sphere || 21 || || fft2 || 23 || || infer || 25 || || maillist || 25 || || mandel || 27 || || nucleic2 || 30 || || primes || 34 || || cichelli || 35 || || ida || 39 || || listcompr || 41 || || listcopy || 43 || || multiplier || 43 || || wang || 43 || || hpg || 45 || || anna || 46 || || reverse-complem || 46 || || integrate || 48 || || primetest || 50 || || paraffins || 54 || || solid || 54 || || puzzle || 55 || || treejoin || 61 || || compress2 || 64 || || compress || 65 || || event || 65 || || bernouilli || 74 || || comp_lab_zift || 78 || || simple || 86 || || wheel-sieve2 || 91 || || life || 100 || || exp3_8 || 102 || || wave4main || 103 || || typecheck || 106 || || atom || 110 || || fulsom || 112 || || CS || 116 || || para || 120 || || kahan || 138 || || transform || 145 || || power || 150 || || cacheprof || 151 || || hidden || 160 || || scs || 168 || || lcss || 175 || || wheel-sieve1 || 199 || || VS || 204 || || pidigits || 216 || || FS || 222 || || last-piece || 230 || || fasta || 263 || || cryptarithm1 || 264 || || CSD || 272 || || digits-of-e1 || 273 || || binary-trees || 342 || || digits-of-e2 || 381 || || circsim || 418 || || S || 451 || || VSM || 497 || || lambda || 617 || || integer || 905 || || n-body || 1043 || || linear || 1070 || || spectral-norm || 1132 || || constraints || 1171 || || exact-reals || 1289 || || mate || 1955 || || fannkuch-redux || 2185 || || k-nucleotide || 2989 || || 17 || || gamteb || 17 || || fft || 18 || || boyer || 20 || || gcd || 20 || || sphere || 21 || || fft2 || 23 || || infer || 25 || || maillist || 25 || || mandel || 27 || || nucleic2 || 30 || || primes || 34 || || cichelli || 35 || || ida || 39 || || listcompr || 41 || || listcopy || 43 || || multiplier || 43 || || wang || 43 || || hpg || 45 || || anna || 46 || || reverse-complem || 46 || || integrate || 48 || || primetest || 50 || || paraffins || 54 || || solid || 54 || || puzzle || 55 || || treejoin || 61 || || compress2 || 64 || || compress || 65 || || event || 65 || || bernouilli || 74 || || comp_lab_zift || 78 || || simple || 86 || || wheel-sieve2 || 91 || || life || 100 || || exp3_8 || 102 || || wave4main || 103 || || typecheck || 106 || || atom || 110 || || fulsom || 112 || || CS || 116 || || para || 120 || || kahan || 138 || || transform || 145 || || power || 150 || || cacheprof || 151 || || hidden || 160 || || scs || 168 || || lcss || 175 || || wheel-sieve1 || 199 || || VS || 204 || || pidigits || 216 || || FS || 222 || || last-piece || 230 || || fasta || 263 || || cryptarithm1 || 264 || || CSD || 272 || || digits-of-e1 || 273 || || binary-trees || 342 || || digits-of-e2 || 381 || || circsim || 418 || || S || 451 || || VSM || 497 || || lambda || 617 || || integer || 905 || || n-body || 1043 || || linear || 1070 || || spectral-norm || 1132 || || constraints || 1171 || || exact-reals || 1289 || || mate || 1955 || || fannkuch-redux || 2185 || || k-nucleotide || 2989 || -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15357> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #14271: ghci hangs with -fexternal-interpreter -prof
by GHC 09 Jan '19

09 Jan '19

#14271: ghci hangs with -fexternal-interpreter -prof ----------------------------------------+------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+------------------------------- {{{ ghci -fexternal-interpreter -prof GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Access violation in generated code when reading 00000001001e0418 }}} * The address remains the same between reruns (and reinstalls) of ghc. * Closing the hanging process leaves the launched ghc active in the background. * The directory I launch ghci from doesn't seem to matter. * I have only tried it on my desktop so far (Win10/Skylake) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14271> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #15938: Hadrian's recompilation check is extremely slow
by GHC 09 Jan '19

09 Jan '19

#15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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 just Ctrl-C'd hadrian while it was building `libraries/base`, having noticed that I forgot to start it with `-j`. I then immediately restarted it and noticed that Hadrian needed to think for 45 seconds before it started even a single build. This is orders of magnitude worse than `make` so something must be wrong. I'm setting this at high priority since 45 seconds is longer than many complete `make` rebuilds. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15938> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 43

[GHC] #14576: Internal error when compiling TH code with profiling on Windows
by GHC 09 Jan '19

09 Jan '19

#14576: Internal error when compiling TH code with profiling on Windows -------------------------------------+------------------------------------- Reporter: lazac | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When using the GHC API with this minimal example, compiled with profiling enabled: {{{#!hs module Main where import GHC import GHC.Paths ( libdir ) main = runGhc (Just libdir) $ do env <- getSession dflags <- getSessionDynFlags setSessionDynFlags dflags target <- guessTarget "A.hs" Nothing setTargets [target] load LoadAllTargets }}} Invoking the main executable: {{{ testprof }}} While A.hs contains a TH splice: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module A where $(return []) }}} The compiler crashes: {{{ testprof.exe: internal error: IMAGE_REL_AMD64_ADDR32[NB]: High bits are set in 10e6109d0 for .text (GHC version 8.2.1 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} The walkaround is to use -fexternal-interpreter, in that case, the crash does not happen. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14576> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #16110: Explicit foralls in associated type family defaults are completely ignored?
by GHC 09 Jan '19

09 Jan '19

#16110: Explicit foralls in associated type family defaults are completely ignored? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While playing around with GHC HEAD recently, I noticed some rather bizarre behavior when trying to use explicit `forall`s with associated type family defaults. Let's pop open GHCi and recreate it: {{{ $ inplace/bin/ghc-stage2 --interactive -XTypeFamilies -XScopedTypeVariables GHCi, version 8.7.20181215: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> class C a where { type T a b; type forall b. T a b = Either a b } }}} OK, so far, so good. Now let's see what happens when I omit the `b`: {{{ λ> class C a where { type T a b; type forall. T a b = Either a b } }}} That... works? Wow, I wouldn't have expected that... But it gets even worse—I can type in utter nonsense, and GHCi will accept it: {{{ λ> class C a where { type T a b; type forall dup dup dup. T a b = Either a b } λ> class C a where { type T a b; type forall (a :: a). T a b = Either a b } λ> class C a where { type T a b; type forall (a :: k) k. T a b = Either a b } }}} How could this possibly happen? After looking at the source code to see how associated type family defaults are renamed, it becomes clear why this is the case. Here is how they are [http://git.haskell.org/ghc.git/blob/ef57272e28f5047599249ae457609a079d8aebe… renamed]: {{{#!hs rnTyFamDefltEqn cls (FamEqn { ... , feqn_bndrs = bndrs , ... }) = do { ... ; return (FamEqn { ... , feqn_bndrs = ASSERT( isNothing bndrs ) Nothing , ... }, ...) } }}} Not only are the type variable binders ignored, there's actually an `ASSERT`ion in place which assumes that there will be no binders whatsoever! (I haven't checked, but I suspect the code above will trigger a failure on that `ASSERT`ion.) My questions after seeing all of this are: * Should we be accepting explicit `forall`s in associated type family defaults at all? * If so, should we remove this strange invariant that the binders will always be `Nothing`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16110> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #16115: Missing associated type instance not reported with error
by GHC 08 Jan '19

08 Jan '19

#16115: Missing associated type instance not reported with error -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 (Type checker) | 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: -------------------------------------+------------------------------------- I noticed [https://stackoverflow.com/questions/53987924/haskell-couldnt- match-expected-type-item-nat-with-actual-type this SO question] was caused by a warning disappearing as a result of the error it caused. {{{#!hs {-# language TypeFamilies, DataKinds #-} module NoWarning where data Nat = Zero | Succ Nat deriving Show class FromList a where type Item a :: * fromList :: [Item a] -> a instance FromList Nat where fromList [] = Zero fromList (a:as) = Succ (fromList as :: Nat) fish :: Nat fish = fromList [(),(),()] }}} If you delete `fish`, you get a nice warning: {{{ NoWarning.hs:8:1: warning: [-Wmissing-methods] • No explicit associated type or default declaration for ‘Item’ • In the instance declaration for ‘FromList Nat’ | 8 | instance FromList Nat where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} But with `fish`, all you get is {{{ NoWarning.hs:13:18: error: • Couldn't match expected type ‘Item Nat’ with actual type ‘()’ • In the expression: () In the first argument of ‘fromList’, namely ‘[(), (), ()]’ In the expression: fromList [(), (), ()] | 13 | fish = fromList [(),(),()] | }}} That warning is the proper explanation of the problem, and it's just missing! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16115> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15578: Honour INLINE pragmas on 0-arity bindings
by GHC 08 Jan '19

08 Jan '19

#15578: Honour INLINE pragmas on 0-arity bindings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently if we see {{{ x = factorial 200 {-# INLINE x #-} f y = ...x... }}} we won't inline `x`, lest we duplicate the work of `factorial 200`. But * Occasionally it's very important to inline `x`: see Trac #15519 for a real-world example. * Suppose `x` is used exactly once, not inside a lambda, thus {{{ x = blah {-# INLINE x #-} g = ...x... }}} Then, if there is ''no'' INLINE pragma, `x` will get inlined (by `preInlineUnconditionally`. But if there ''is'' an INLINE pragma, currently `x` is ''not'' inlined by `preInlineUnconditionally`: see `Note [Stable unfoldings and preInlineUnconditionally]` in `SimplUtils`. This is insane! * INLINE says "inline me at every saturated call", where "saturated" is determined by the number of arguments syntactically to the left of the "=" in the source bindings. In this case, there are no arguments to the left, so every occurrence is saturated. So it's inconsistent not to inline. Bottom line: if a 0-ary binding has an INLINE pragma, I think we should inline it at every use site * Regardless of the work duplication * Including inside lambdas Note, however, that there is a real risk that full laziness will float it right back out again. Consider again {{{ x = factorial 200 {-# INLINE x #-} f y = ...x... }}} After inlining we get {{{ f y = ...(factorial 200)... }}} but it's entirely possible that full laziness will do {{{ lvl23 = factorial 200 f y = l...lvl23... }}} That's a problem for another day. Presumably the reason the user wanted to inline it was to get some rule to fire, and this change gives at least some chance that will happen, and makes INLINE behave consistently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15578> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #13962: GHCi allows unsaturated type family
by GHC 08 Jan '19

08 Jan '19

#13962: GHCi allows unsaturated type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: -------------------------------------+------------------------------------- Taken from [http://ics.p.lodz.pl/~stolarek/_media/pl:research:promotion- haskell14-slides.pdf Promoting Functions to Type Families in Haskell] {{{#!hs {-# Language TypeFamilies, PolyKinds, DataKinds, TypeOperators #-} type family Map (f :: a -> b) (xs :: [a]) :: [b] where Map f '[] = '[] Map f (x ': xs) = f x ': Map f xs data N = O | S N type family Pred (n :: N) :: N where Pred O = O Pred (S n) = n -- The type family ‘Map’ should have 2 arguments, but has been given 1 type MapPred = Map Pred }}} fails as expected, but it works in GHCi {{{ ghci> :kind Map Pred Map Pred :: [N] -> [N] ghci> :kind! Map Pred '[S (S O), S O, O] Map Pred '[S (S O), S O, O] :: [N] = '['S 'O, 'O, 'O] }}} I can only test this in GHC 7.8, 8 now. I know GHCi has weird rules for unsaturated type families but I figured I'd write a ticket because the slides say "But it is invalid to write: `Map Pred '[O, S O]`". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13962> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14677: Code generator does not correctly tag a pointer
by GHC 08 Jan '19

08 Jan '19

#14677: Code generator does not correctly tag a pointer -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Consider {{{ data T a = MkT ![a] }}} The pointer stored in a `MkT` constructor should always be correctly tagged, never tagged with un-evaluated 00. C.f. [wiki:Commentary/Rts/HaskellExecution/PointerTagging] But this invariant is broken. Example taken from #14626, comment:37-39. Trac14626_1.hs {{{ module Trac14626_1 where data Style = UserStyle Int | PprDebug data SDC = SDC !Style !Int defaultUserStyle :: Bool -> Style defaultUserStyle True = UserStyle 123 defaultUserStyle False = PprDebug }}} Trac14626_2.hs {{{ module Trac14626_2 where import Trac14626_1 f :: Int -> SDC f x = SDC (defaultUserStyle (x > 1)) x }}} Compiling with `ghc Trac14626_1 Trac14626_2 -ddump-simpl -O` results in a similar scenario than the one described by Heisenbug: {{{ -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} defaultUserStyle2 defaultUserStyle2 = I# 123# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} defaultUserStyle1 defaultUserStyle1 = UserStyle defaultUserStyle2 -- RHS size: {terms: 7, types: 2, coercions: 0, joins: 0/0} defaultUserStyle defaultUserStyle = \ ds_dZ7 -> case ds_dZ7 of { False -> PprDebug; True -> defaultUserStyle1 } }}} Our `UserStyle 123` constant has been lifted to top-level, just like in Heisenbugs example. Now looking at the Core of `f` {{{ f f = \ x_a1dk -> case x_a1dk of { I# x1_a2gV -> case ># x1_a2gV 1# of { __DEFAULT -> SDC PprDebug x1_a2gV; 1# -> SDC defaultUserStyle1 x1_a2gV } } }}} (Note how `f` doesn't scrutinise defaultUserStyle1) Looking at the CMM for `f` we can see {{{ ... if (%MO_S_Le_W64(_s2hT::I64, 1)) goto c2ip; else goto c2is; c2ip: I64[Hp - 16] = SDC_con_info; P64[Hp - 8] = PprDebug_closure+2; I64[Hp] = _s2hT::I64; R1 = Hp - 15; Sp = Sp + 8; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; c2is: I64[Hp - 16] = SDC_con_info; P64[Hp - 8] = defaultUserStyle1_closure; -- defaultUserStyle1 isn't tagged! I64[Hp] = _s2hT::I64; R1 = Hp - 15; Sp = Sp + 8; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; }}} When generating code for f the code generator wants to know the `LambdaFormInfo` (the closure type) of `defaultUserStyle1`. Since `defaultUserStyle1` is defined in another module we end up calling `mkLFImported` in `StgCmmClosure` which ultimatively gives an `LFUnknown` which always gets a `DynTag` 0 from `lfDynTag`. I think we lack a bit of information here to give defaultUserStyle1 the correct `LFCon` lambda form. Maybe top-level binders should know its `LambdaForm` and include them in their interfaces. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14677> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33