November 2017 - ghc-tickets

[GHC] #14120: stg-lint is hopelessly broken
by GHC 28 Nov '17

28 Nov '17

#14120: stg-lint is hopelessly broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Today I spent a fair amount of time looking at the STG linter, having encountered a number of times in the past six months where I noticed it broke. While I thought fixing it would just be a few small tweaks, it seems that with every issue I fix another bug rears its ugly head. So far I have encountered and fixed, * #14116 * #14117 * #14118 The solutions to each of these has seemed rather obvious. However, now I seem to have run into a bit of a more fundamental issue: Consider this excerpt extracted from `Foreign.Storable`, {{{#!hs {-# LANGUAGE BangPatterns #-} module Hi where import GHC.Word import GHC.Ptr import GHC.Base import GHC.Num import Data.Bits import GHC.Fingerprint.Type peekFingerprint :: Ptr Fingerprint -> IO Fingerprint peekFingerprint p0 = do let peekW64 :: Ptr Word8 -> Int -> Word64 -> IO Word64 peekW64 _ 0 !i = return i peekW64 !p !n !i = peekW64 (p `plusPtr` 1) (n-1) (i `shiftL` 8) high <- peekW64 (castPtr p0) 8 0 low <- peekW64 (castPtr p0 `plusPtr` 8) 8 0 return (Fingerprint high low) }}} In particular notice the `castPtr` application. This triggers the STG linter with, {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170815 for x86_64-unknown-linux): *** Stg Lint ErrMsgs: in Stg2Stg *** <no location info>: warning: [in body of lambda with binders p0_s2zB :: Ptr Fingerprint, eta_s2zC :: State# RealWorld] In a function application, function type doesn't match arg types: Function type: Ptr Word8 -> Int# -> Word# -> State# RealWorld -> (# State# RealWorld, Word64 #) Arg types: Ptr Fingerprint Int# Word# State# RealWorld Expression: $wpeekW64 p0_s2zB 8# 0## eta_s2zC }}} This is because by the time we are in Core Prep the `castPtr` is turned into a cast, which we discard in STG. Consequently, it seems that the comment attached to `stgEqType`, {{{#!hs stgEqType :: Type -> Type -> Bool -- Compare types, but crudely because we have discarded -- both casts and type applications, so types might look -- different but be the same. So reply "True" if in doubt. -- "False" means that the types are definitely different. -- -- Fundamentally this is a losing battle because of unsafeCoerce }}} is quite an understatement. Rather, there are exceedingly few cases where we can catch any type errors in STG. I think the only case which we can reliably catch is that of two types with explicitly different primreps. It's not clear what we can/should do about this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14120> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14116: Core lint error while compiling master
by GHC 28 Nov '17

28 Nov '17

#14116: Core lint error while compiling master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- While compiling e054c5f06451def4437d9d770ae156f034796c59 with the following `build.mk`, {{{ BuildFlavour = devel2 include mk/flavours/$(BuildFlavour).mk GhcStage2HcOpts += -eventlog GhcStage1HcOpts += -eventlog GhcLibHcOpts += -g3 -ddump-to-file -ddump-stg -dcore-lint -dstg-lint -dcmm-lint GhcRtsHcOpts += -g3 GhcStage2HcOpts += -g3 -ddump-to-file -ddump-stg -dcore-lint -dstg-lint -dcmm-lint }}} I encountered this Core lint failure while compiling `PprColour`, {{{ stgEqType: unequal PprColour [Char] ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170815 for x86_64-unknown-linux): *** Stg Lint ErrMsgs: in Stg2Stg *** compiler/utils/PprColour.hs:62:1: warning: [RHS of defaultScheme :: Scheme] In a RHS constructor application, con type doesn't match arg types: Constructor type: PprColour -> PprColour -> PprColour -> PprColour -> PprColour -> PprColour -> Scheme Arg types: [Char] PprColour String String String String *** Offending Program *** ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14116> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14527: Warn on recursive bindings
by GHC 28 Nov '17

28 Nov '17

#14527: Warn on recursive bindings -------------------------------------+------------------------------------- Reporter: chrisdone | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- When you accidentally write something like `let x = .. x ...` it can take hours to realize where you made your mistake. This hits me once in a while, and my colleagues often. I'd propose e.g. `-Wrecursive-bindings` that says: {{{ warning: [-Wrecursive-bindings] Recursive binding for `x` in let x = length x }}} This applies to `let`, `where` and top-level pattern bindings. I believe that in practice, I only actually use real recursive bindings once in a while. So I might be bold enough to encourage enabling it in `-Wall` for a future major GHC release. With the compromise that if you have the warning enabled but in one specific place, you want a recursive binding, you can use the `~` tilde to say "I really mean it", e.g. {{{let ~ones = 1 : ones}}} That seems like a nice balance to say "I know what I'm doing in this case". So the warning could be more helpful, like: {{{ warning: [-Wrecursive-bindings] Recursive binding for `ones` in let ones = length ones If intentional, use the tilde marker on the name like this: let ~ones = length ones }}} In Intero if I were to implement a prototype of this check, I'd probably do this, after renaming: 1. Use SYB to collect all variable bindings from the pattern. 2. Use SYB to listify all mentions of any of these variables in the RHS and any guards or where clauses. If the list is non-empty, then trigger the error. A transformation function {{{[Name] -> Pat -> Pat}}} would provide the AST with the offending name(s) tilded as {{{~x}}} for use in the error message. If there's general agreement, I could implement this change. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14527> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #14459: `make sdist-ghc` broken
by GHC 28 Nov '17

28 Nov '17

#14459: `make sdist-ghc` broken -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 8.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 noticed this because it resulted in the PPA builds of GHC HEAD failing; I was able to hunt this down to bdd2d2862e248948efafa8ba4219e94825ddf21a which updated `libraries/Cabal`; Basically, the following invocation (where `ghc`/`alex`/`happy`/etc. can only be found in `/opt/ghc-stage0-toolchain/bin`, and nowhere else; so this relies on `configure` to capture their absolute locations; however, this is not what causes the failure below) {{{#!bash ./boot PATH=/opt/ghc-stage0-toolchain/bin:$PATH ./configure make sdist-ghc }}} results in {{{ ... test ! -d testsuite || make -C testsuite distclean "rm" -rf sdistprep/ghc/ghc-8.3.20171109/libraries/tarballs/ "rm" -rf sdistprep/ghc/ghc-8.3.20171109/libraries/stamp/ "rm" -rf sdistprep/ghc/ghc-8.3.20171109/compiler/stage[123] "rm" -f sdistprep/ghc/ghc-8.3.20171109/mk/build.mk for i in parallel random primitive vector dph; do rm -rf sdistprep/ghc/ghc-8.3.20171109/libraries/$i/; done cd sdistprep/ghc/ghc-8.3.20171109 && "/usr/bin/find" mk rules docs distrib bindisttest libffi includes utils docs rts compiler ghc driver libraries libffi-tarballs iserv $ -name .git -o -name "autom4te*" -o -name "*~" -o -name "\#*" -o -name ".\#*" -o -name "log" -o -name "*-SAVE" -o -name "*.orig" -o -name "*.rej" $ -print | "xargs" "rm" -rf "cp" compiler/stage2/build/CmmLex.hs sdistprep/ghc/ghc-8.3.20171109/compiler/cmm mv sdistprep/ghc/ghc-8.3.20171109/compiler/cmm/CmmLex.x sdistprep/ghc/ghc-8.3.20171109/compiler/cmm/CmmLex.x.source "/opt/ghc-stage0-toolchain/bin/happy" -agc --strict compiler/cmm/CmmParse.y -o compiler/stage2/build/CmmParse.hs "cp" compiler/stage2/build/CmmParse.hs sdistprep/ghc/ghc-8.3.20171109/compiler/cmm mv sdistprep/ghc/ghc-8.3.20171109/compiler/cmm/CmmParse.y sdistprep/ghc/ghc-8.3.20171109/compiler/cmm/CmmParse.y.source "/opt/ghc-stage0-toolchain/bin/alex" -g --latin1 compiler/parser/Lexer.x -o compiler/stage2/build/Lexer.hs "cp" compiler/stage2/build/Lexer.hs sdistprep/ghc/ghc-8.3.20171109/compiler/parser mv sdistprep/ghc/ghc-8.3.20171109/compiler/parser/Lexer.x sdistprep/ghc/ghc-8.3.20171109/compiler/parser/Lexer.x.source "/opt/ghc-stage0-toolchain/bin/happy" -agc --strict compiler/parser/Parser.y -o compiler/stage2/build/Parser.hs "cp" compiler/stage2/build/Parser.hs sdistprep/ghc/ghc-8.3.20171109/compiler/parser mv sdistprep/ghc/ghc-8.3.20171109/compiler/parser/Parser.y sdistprep/ghc/ghc-8.3.20171109/compiler/parser/Parser.y.source "inplace/bin/mkdirhier" utils/hpc/dist-install/build//. "/opt/ghc-stage0-toolchain/bin/happy" -agc --strict utils/hpc/./HpcParser.y -o utils/hpc/dist-install/build/HpcParser.hs unused terminals: 1 "cp" utils/hpc/dist-install/build/HpcParser.hs sdistprep/ghc/ghc-8.3.20171109/utils/hpc/ mv sdistprep/ghc/ghc-8.3.20171109/utils/hpc//HpcParser.y sdistprep/ghc/ghc-8.3.20171109/utils/hpc//HpcParser.y.source "inplace/bin/mkdirhier" utils/genprimopcode/dist/build//. "/opt/ghc-stage0-toolchain/bin/alex" -g utils/genprimopcode/./Lexer.x -o utils/genprimopcode/dist/build/Lexer.hs "cp" utils/genprimopcode/dist/build/Lexer.hs sdistprep/ghc/ghc-8.3.20171109/utils/genprimopcode/ mv sdistprep/ghc/ghc-8.3.20171109/utils/genprimopcode//Lexer.x sdistprep/ghc/ghc-8.3.20171109/utils/genprimopcode//Lexer.x.source "/opt/ghc-stage0-toolchain/bin/happy" -agc --strict utils/genprimopcode/./Parser.y -o utils/genprimopcode/dist/build/Parser.hs "cp" utils/genprimopcode/dist/build/Parser.hs sdistprep/ghc/ghc-8.3.20171109/utils/genprimopcode/ mv sdistprep/ghc/ghc-8.3.20171109/utils/genprimopcode//Parser.y sdistprep/ghc/ghc-8.3.20171109/utils/genprimopcode//Parser.y.source make[1]: *** No rule to make target 'libraries/Cabal/Cabal/dist- install/build/Distribution/Parsec/Lexer.hs', needed by 'sdist_libraries/Cabal/Cabal_dist-install_Lexer'. Stop. Makefile:161: recipe for target 'sdist-ghc' failed make: *** [sdist-ghc] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14459> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14516: getGCStats was broken in 8.2
by GHC 27 Nov '17

27 Nov '17

#14516: getGCStats was broken in 8.2 -------------------------------------+------------------------------------- Reporter: chrisdone | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.2.1 libraries/base | 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: -------------------------------------+------------------------------------- The {{{getGCStats}}} function from {{{GHC.Stats}}} defined [http://hackage.haskell.org/package/base-4.10.0.0/docs/GHC-Stats.html#g:2 here] expects the {{{numGCs}}} field to be an {{{Int64}}}, but in the new {{{RTSStats}}} API, it's a {{{Word32}}}, so the function inside is no longer correct: {{{ getGCStats = do ... allocaBytes ((232)) $ \p -> do {-# LINE 284 "GHC/Stats.hsc" #-} getRTSStats_ p bytesAllocated <- ((\hsc_ptr -> peekByteOff hsc_ptr 8)) p {-# LINE 286 "GHC/Stats.hsc" #-} numGcs <- ((\hsc_ptr -> peekByteOff hsc_ptr 0)) p {-# LINE 287 "GHC/Stats.hsc" #-} numByteUsageSamples <- ((\hsc_ptr -> peekByteOff hsc_ptr 4)) p }}} The {{{numGcs}}} line peeks off 8 bytes instead of 4, and so it leads to packages like my {{{weigh}}} package claiming that you've done "4,294,967,299" garbage collections. I've updated {{{weigh}}} to use the new API with some CPP {{{#if}}}'s. Given that the new API changes pretty much everything, both names and types (it took a couple hours to make weigh support the old and the new one), and that the old "compatibility" API is returning bad results, honestly I wouldn't have minded if the old API was just removed in 8.2. Leaving it up to you whether this should be fixed in an 8.2.3 bugfix release or just leave it to be removed in 8.4. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14516> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #2401: aborting an STM transaction should throw an exception
by GHC 27 Nov '17

27 Nov '17

#2401: aborting an STM transaction should throw an exception -------------------------------------+------------------------------------- Reporter: sclv | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 6.8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by akio): * cc: akio (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2401#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14532: Missing constant folding for Numeric.Natural
by GHC 27 Nov '17

27 Nov '17

#14532: Missing constant folding for Numeric.Natural -------------------------------------+------------------------------------- Reporter: reinerp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- The following Haskell code {{{#!hs module Zero where import Numeric.Natural zero :: Natural zero = 0 }}} generates this Core: {{{#!hs -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} zero1 zero1 = 0 -- RHS size: {terms: 39, types: 12, coercions: 0, joins: 0/0} zero zero = case zero1 of { S# i#_a2c6 -> case tagToEnum# (>=# i#_a2c6 0#) of { False -> underflowError; True -> NatS# (int2Word# i#_a2c6) }; Jp# dt_a2cg -> case uncheckedIShiftRL# (sizeofByteArray# dt_a2cg) 3# of { __DEFAULT -> case sizeofByteArray# dt_a2cg of { __DEFAULT -> NatJ# dt_a2cg; 0# -> underflowError }; 1# -> case indexWordArray# dt_a2cg 0# of wild2_a2ck { __DEFAULT -> NatS# wild2_a2ck } }; Jn# ipv_a2cn -> underflowError } }}} It should instead generate this: {{{#!hs zero = NatS# 0## }}} This kind of code is generated whenever one uses `GHC.TypeLits.natVal`, even at a constant `Nat`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14532> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14449: Type variables allowed to unify in a partial type signature (PartialTypeSignatures)
by GHC 27 Nov '17

27 Nov '17

#14449: Type variables allowed to unify in a partial type signature (PartialTypeSignatures) -------------------------------------+------------------------------------- Reporter: kcsongor | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | 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: -------------------------------------+------------------------------------- During a discussion today, Richard discovered the following bug: The function `f` is accepted in GHC 8.2.1 (and HEAD too): {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} f :: a -> b -> _ f x y = [x, y] }}} with the warning: {{{ Bug.hs:3:16: warning: [-Wpartial-type-signatures] • Found type wildcard ‘_’ standing for ‘[a]’ Where: ‘a’ is a rigid type variable bound by the inferred type of f :: a -> a -> [a] at Bug.hs:4:1-13 • In the type signature: f :: a -> b -> _ | 3 | f :: a -> b -> _ | ^ Ok, 1 module loaded. }}} This is a regression compared to 8.0.1, where the following error is produced (rightly): {{{ Bug.hs:4:12: error: • Couldn't match expected type ‘a’ with actual type ‘b’ ‘b’ is a rigid type variable bound by the inferred type of f :: a -> b -> [a] at Bug.hs:3:6 ‘a’ is a rigid type variable bound by the inferred type of f :: a -> b -> [a] at Bug.hs:3:6 • In the expression: y In the expression: [x, y] In an equation for ‘f’: f x y = [x, y] • Relevant bindings include y :: b (bound at Bug.hs:4:5) x :: a (bound at Bug.hs:4:3) f :: a -> b -> [a] (bound at Bug.hs:4:1) Failed, modules loaded: none. }}} Note that the inferred type of `f` is still correct: `f :: a -> a -> a`, but the type variables `a` and `b` are allowed to unify during inference, and they shouldn't be. If I understood correctly, this implies that when inferring the type of functions with partial type signatures, the type variables are (wrongly) treated as `SigTv`s, instead of skolem constants. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14449> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13110: GHC API allocates memory which is never GC'd
by GHC 27 Nov '17

27 Nov '17

#13110: GHC API allocates memory which is never GC'd -------------------------------------+------------------------------------- Reporter: DanielG | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | 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've run into a very strange sort of memory leak it seems. GHC seems to manage to allocate memory which I cannot get rid of no matter what I try even after all references have disappeared. The allocated memory doesn't show up in heap profiles but is still visibly allocated (as seen in ps or pmap). I discovered this while investigating reports of large memory usage in ghc-mod where this issue is forcing us to dump completion information in a separate process to avoid the allocated memory sticking around for the rest of the user's session. The attached test case demonstrates this problem by first calling `getModuleInfo` for all modules in all visible packages and then just looping forever in `main`. I would expect all memory GHC allocated to be GC'd at this point but this does not happen. When run as {{{ $ ./Leaky -hide-all-packages }}} the test case consumes around 30M of memory on my system, if we however load some large package, say GHC itself {{{ $ ./Leaky -hide-all-packages -package ghc }}} the program will consume around 2-300M of memory which are never deallocated. The behaviour is not related to the loaded package though I tried it with `Cabal` too with the same result though smaller memory usage. At first I thought this might be related to large CAFs with IORefs inside not being GCd for some reason so I tried calling `resetCAFs` from the RTS before entering the loop. This however makes no difference whatsoever. I also tried forcing a major GC just to be save to no avail. Next I speculated that maybe the allocated memory is beyond the GC's control (malloc()ed or something) but looking at the memory map of the process with `pmap $(pgrep Leaky)` that the majority of the memory usage I'm seeing comes from address `0x0000000200000000` which is where the RTS allocates memory AFAIK. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13110> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #14514: Higher-Rank Kinds work in ADT but not GADT
by GHC 26 Nov '17

26 Nov '17

#14514: Higher-Rank Kinds work in ADT but not GADT -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Following code from [https://github.com/goldfirere/triptych/blob/2e21a6be4419873c77a02c9a198379c… Richard's 2016 Haskell Implementors' Workshop talk] (/ [https://arxiv.org/abs/1610.04799 Trees That Grow]) works just fine {{{#!hs {-# Language RankNTypes, KindSignatures, DataKinds, TypeFamilyDependencies, TypeInType #-} import Data.Kind data TagTag = ETagTag | PTagTag data ETag = VarTag data PTag = VarPTag type family Tag (ttag::TagTag) = (res :: Type) | res -> ttag where Tag ETagTag = ETag Tag PTagTag = PTag type WithAnyTag = forall tag. Tag tag -> Type -- data Exp (ext::WithAnyTag) where -- Var :: ext VarTag -> Exp ext data Exp (ext::WithAnyTag) = Var (ext VarTag) }}} but replace `data Exp` with its commented-out GADT brethren and it stops working {{{ $ ghci -ignore-dot-ghci Weird.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Weird.hs, interpreted ) Weird.hs:17:28: error: • Expected kind ‘WithAnyTag’, but ‘ext1’ has kind ‘ETag -> *’ • In the first argument of ‘Exp’, namely ‘ext’ In the type ‘Exp ext’ In the definition of data constructor ‘Var’ | 17 | Var :: ext VarTag -> Exp ext | ^^^ Failed, 0 modules loaded. Prelude> }}} The type synonym can be inlined, makes no difference. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14514> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5