- ghc-tickets - Haskell.org

[GHC] #14555: GHC Panic with TypeInType / levity polymorphism
by GHC 12 Dec '17

12 Dec '17

#14555: GHC Panic with TypeInType / levity polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism, TypeInType | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language TypeInType #-} {-# Language TypeOperators, DataKinds, PolyKinds #-} import Data.Kind import GHC.Types (TYPE) data Exp :: [TYPE rep] -> TYPE rep -> Type where Lam :: Exp (a:xs) b -> Exp xs (a -> b) }}} gives {{{ $ ghci -ignore-dot-ghci hs/126-bug.hs GHCi, version 8.3.20171122: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( hs/126-bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20171122 for x86_64-unknown-linux): zonkTcTyVarToVar 'LiftedRep Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1147:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcType.hs:1640:17 in ghc:TcType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} caused by `TypeInType`. Removing the first line, we get an error {{{ GHCi, version 8.3.20171122: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( hs/126-bug.hs, interpreted ) hs/126-bug.hs:7:19: error: • Expected kind ‘GHC.Types.RuntimeRep’, but ‘rep’ has kind ‘*’ • In the first argument of ‘TYPE’, namely ‘rep’ In the kind ‘[TYPE rep] -> TYPE rep -> Type’ | 7 | data Exp :: [TYPE rep] -> TYPE rep -> Type where | ^^^ hs/126-bug.hs:7:32: error: • Expected kind ‘GHC.Types.RuntimeRep’, but ‘rep’ has kind ‘*’ • In the first argument of ‘TYPE’, namely ‘rep’ In the kind ‘[TYPE rep] -> TYPE rep -> Type’ | 7 | data Exp :: [TYPE rep] -> TYPE rep -> Type where | ^^^ Failed, no modules loaded. Prelude> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14555> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14563: GHC Panic with TypeInType / levity polymorphism
by GHC 12 Dec '17

12 Dec '17

#14563: GHC Panic with TypeInType / levity polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism, TypeInType | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14555 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code is rightfully rejected. {{{#!hs -- {-# Language TypeInType #-} {-# Language RankNTypes, KindSignatures, PolyKinds #-} import GHC.Types (TYPE) import Data.Kind data Lan (g::TYPE rep -> TYPE rep') (h::TYPE rep -> TYPE rep'') a where Lan :: forall xx (g::TYPE rep -> TYPE rep') (h::TYPE rep -> Type) a. (g xx -> a) -> h xx -> Lan g h a }}} But uncomment first line and it panics {{{ $ ghci2 ~/hs/132-bug.hs GHCi, version 8.3.20171122: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /home/baldur/hs/132-bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20171122 for x86_64-unknown-linux): zonkTcTyVarToVar 'LiftedRep Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1147:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcType.hs:1640:17 in ghc:TcType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} Maybe the same as #14555. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14563> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9669: Long compile time/high memory usage for modules with many deriving clauses
by GHC 12 Dec '17

12 Dec '17

#9669: Long compile time/high memory usage for modules with many deriving clauses -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile- Difficulty: Unknown | time performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I've seen many different people complain about this in various different contexts. One of the most common I personally see is when using Persistent with a large number of entities, which results in multi-minute build times for that single module. Usually, these reports have come from private repositories, which makes for a difficult repro. Also, the usage of Template Haskell in those modules tends to confuse the issue. So I'd like to report this issue from a completely separate project, with the guess that this represents an issue that is affecting many other users. Steps to reproduce: * `cabal unpack fpco-api-1.2.0.1` * `cd fpco-api-1.2.0.1` * `cabal install` * `ghc --make -isrc/library src/library/FP/API/Types.hs` * `touch src/library/FP/API/Types.hs` Then, to see the time and memory usage of compiling just the one module, run: * `time ghc -O2 --make -isrc/library src/library/FP/API/Types.hs +RTS -s` On my system (16GB RAM, quadcore i7), the results are: {{{ $ time ghc -O2 --make -isrc/library src/library/FP/API/Types.hs +RTS -s [3 of 3] Compiling FP.API.Types ( src/library/FP/API/Types.hs, src/library/FP/API/Types.o ) 51,846,533,568 bytes allocated in the heap 6,799,246,288 bytes copied during GC 389,297,584 bytes maximum residency (22 sample(s)) 11,330,472 bytes maximum slop 1041 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2041 colls, 0 par 9.19s 9.19s 0.0045s 0.0998s Gen 1 22 colls, 0 par 4.33s 4.33s 0.1969s 0.5436s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.00s ( 0.00s elapsed) MUT time 34.21s ( 37.74s elapsed) GC time 13.52s ( 13.53s elapsed) EXIT time 0.07s ( 0.07s elapsed) Total time 47.81s ( 51.34s elapsed) Alloc rate 1,515,662,937 bytes per MUT second Productivity 71.7% of total user, 66.8% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 real 0m51.375s user 0m50.864s sys 0m0.456s }}} By contrast, with optimizations turned off: {{{ $ time ghc -O0 --make -isrc/library src/library/FP/API/Types.hs +RTS -s [3 of 3] Compiling FP.API.Types ( src/library/FP/API/Types.hs, src/library/FP/API/Types.o ) 12,767,593,936 bytes allocated in the heap 1,078,202,664 bytes copied during GC 179,551,768 bytes maximum residency (13 sample(s)) 6,684,544 bytes maximum slop 439 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 623 colls, 0 par 1.24s 1.24s 0.0020s 0.0651s Gen 1 13 colls, 0 par 0.76s 0.76s 0.0586s 0.2397s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.00s ( 0.00s elapsed) MUT time 8.28s ( 9.23s elapsed) GC time 2.00s ( 2.00s elapsed) EXIT time 0.05s ( 0.05s elapsed) Total time 10.34s ( 11.28s elapsed) Alloc rate 1,542,443,897 bytes per MUT second Productivity 80.6% of total user, 73.9% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 real 0m11.304s user 0m11.108s sys 0m0.172s }}} and -O1: {{{ $ time ghc -O1 --make -isrc/library src/library/FP/API/Types.hs +RTS -s [3 of 3] Compiling FP.API.Types ( src/library/FP/API/Types.hs, src/library/FP/API/Types.o ) 45,550,443,664 bytes allocated in the heap 5,721,700,512 bytes copied during GC 358,036,456 bytes maximum residency (21 sample(s)) 9,167,176 bytes maximum slop 906 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 1642 colls, 0 par 7.70s 7.70s 0.0047s 0.1031s Gen 1 21 colls, 0 par 3.68s 3.69s 0.1756s 0.4968s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.00s ( 0.00s elapsed) MUT time 30.21s ( 33.09s elapsed) GC time 11.38s ( 11.39s elapsed) EXIT time 0.07s ( 0.07s elapsed) Total time 41.68s ( 44.55s elapsed) Alloc rate 1,507,571,106 bytes per MUT second Productivity 72.7% of total user, 68.0% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 real 0m44.577s user 0m44.164s sys 0m0.368s }}} Note that this module is essentially just 900 lines of data declarations, with a large number of derived classes, and a few manually written helper functions and instances. This high memory usage hasn't just resulted in user complaints: automated Jenkins and Travis jobs will often times fail without optimizations disabled, which can be problematic for proper testing and production code. In the case of fpco-api, I've worked around this by adding `-O0` to the cabal file, but it would be much nicer to not have to do that. For some other examples of complaints along these lines: * https://groups.google.com/d/msg/yesodweb/MX1bnOFu8Hc/VLQXhnvpIkMJ * https://groups.google.com/d/msg/yesodweb/XPWixNjuOnM/FN26bmkudgwJ I believe there are a few other threads discussing this, if it would be helpful. I did my testing on GHC 7.8.3 64-bit, Ubuntu 12.04. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9669> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #13604: regression in ghc 8.2.1-rc1 (8.2.0.2017040)
by GHC 11 Dec '17

11 Dec '17

#13604: regression in ghc 8.2.1-rc1 (8.2.0.2017040) -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In 8.2.1-rc1 loading a file compiled with -O2 into ghci results in ghci recompiling the file into interpreted byte code. In 8.0.2 it simply loads the compiled object file. 8.2.1 {{{ ghc -dynamic -O2 eh2.hs [1 of 1] Compiling Main ( eh2.hs, eh2.o ) Linking eh2 ... bash-3.2$ ghci -ignore-dot-ghci GHCi, version 8.2.0.20170404: http://www.haskell.org/ghc/ :? for help Prelude> :load eh2 [1 of 1] Compiling Main ( eh2.hs, interpreted ) [flags changed] Ok, modules loaded: Main. }}} 8.0.2 {{{ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.2 bash-3.2$ pwd /Users/gcolpitts/haskell bash-3.2$ ghc -dynamic -O2 eh2.hs [1 of 1] Compiling Main ( eh2.hs, eh2.o ) Linking eh2 ... bash-3.2$ ghci -ignore-dot-ghci GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> :load eh2 Ok, modules loaded: Main (eh2.o). }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13604> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 52

[GHC] #14545: -prof causes -N to default to 1
by GHC 11 Dec '17

11 Dec '17

#14545: -prof causes -N to default to 1 -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given a simple test program which prints `getNumCapabilities`: {{{#!hs import Control.Concurrent main :: IO () main = print =<< getNumCapabilities }}} Compiling this with `-threaded` and running the program with `+RTS -N` is supposed to set the number of capabilities to the number of cores on the machine. This normally prints 8 on my machine: {{{#!bash $ rm -rf Main Main.hi Main.o && ghc -threaded Main.hs && ./Main +RTS -N [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... 8 }}} But when I compile with `-prof`, it prints 1 instead! Expected output: still 8. {{{#!bash $ rm -rf Main Main.hi Main.o && ghc -prof -threaded Main.hs && ./Main +RTS -N [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... 1 }}} If I use `+RTS -N8` instead, it prints 8 as expected. Reproduced with GHC 8.0.2 and GHC 8.8.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14545> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14520: GHC panic (TypeInType)
by GHC 11 Dec '17

11 Dec '17

#14520: GHC panic (TypeInType) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language TypeInType, TypeFamilies, TypeOperators #-} import Data.Kind type a ~>> b = (a, b) -> Type data family Sing (a::k) type family (·) (f::a~>>b) (x::a)::b class PCategory kat where type Id ::kat·a·a type Comp::kat·b·c -> kat·a·b -> kat·a·c class SCategory kat where sId :: Sing a -> Sing (Id::kat a a) sComp :: Sing f -> Sing g -> Sing (Comp f g) }}} triggers a panic {{{ $ ghci -ignore-dot-ghci Bug.hs GHCi, version 8.3.20171122: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20171122 for x86_64-unknown-linux): piResultTy k_a1KI[tau:1] a_a1vb[sk:1] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1147:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:951:35 in ghc:Type piResultTy, called at compiler/types/Type.hs:2309:34 in ghc:Type typeKind, called at compiler/types/Type.hs:2309:46 in ghc:Type typeKind, called at compiler/typecheck/TcType.hs:1706:11 in ghc:TcType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14520> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14571: RFE: Make template-haskell cabal package require a specific version of GHC
by GHC 11 Dec '17

11 Dec '17

#14571: RFE: Make template-haskell cabal package require a specific version of GHC ----------------------------------------+--------------------------- Reporter: atodorov | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------- Following a conversation on another bug tracker: https://github.com/bos/math-functions/issues/52 it looks like template-haskell is very dependent on the version of GHC being used (although the test matrix is all green at present). In the above case we're trying to use template-haskell 2.12.0.0 with GHC 8.0.2 to build another package and that fails. One of the problems is that on Fedora template-haskell is shipped separately from GHC while on Debian or with source installations it comes bundled with GHC. Is it possible to specify a requirement on the GHC version inside .cabal files? This will make it easier to track down why something isn't able to compile. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14571> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14568: Uncurried Parameter to n-ary Function in Type Signature Causes Crash
by GHC 09 Dec '17

09 Dec '17

#14568: Uncurried Parameter to n-ary Function in Type Signature Causes Crash -------------------------------------+------------------------------------- Reporter: nixy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- If you uncomment the arrow, everything's fine; GHC crashes as-is. {{{#!hs f :: (a -> b) {- -> -} a -> c f = undefined }}} Apparently GHC incorrectly parses any n-ary function parameter followed by another uncurried parameter in type signatures. System Info: GHC v8.2.1 GCC v5.4.0 Linux Mint (Linux 4.8.0-53-generic #56~16.04.1-Ubuntu SMP x86_64) ghc -v -dcore-lint: {{{ Glasgow Haskell Compiler, Version 8.2.1, stage 2 booted by GHC version 8.0.2 Using binary package database: /usr/local/haskell/ghc-8.2.1-x86_64/lib/ghc-8.2.1/package.conf.d/package.cache Using binary package database: /home/nic/.ghc/x86_64-linux-8.2.1/package.conf.d/package.cache package flags [] loading package database /usr/local/haskell/ghc-8.2.1-x86_64/lib/ghc-8.2.1/package.conf.d loading package database /home/nic/.ghc/x86_64-linux-8.2.1/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.1.0 wired-in package integer-gmp mapped to integer-gmp-1.0.1.0 wired-in package base mapped to base-4.10.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.12.0.0 wired-in package ghc mapped to ghc-8.2.1 wired-in package dph-seq not found. wired-in package dph-par not found. package flags [] loading package database /usr/local/haskell/ghc-8.2.1-x86_64/lib/ghc-8.2.1/package.conf.d loading package database /home/nic/.ghc/x86_64-linux-8.2.1/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.1.0 wired-in package integer-gmp mapped to integer-gmp-1.0.1.0 wired-in package base mapped to base-4.10.0.0 wired-in package rts mapped to rts-1.0 wired-in package template-haskell mapped to template-haskell-2.12.0.0 wired-in package ghc mapped to ghc-8.2.1 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *bug.hs !!! Chasing dependencies: finished in 1.14 milliseconds, allocated 0.207 megabytes Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2017-12-08 23:11:58.321654412 UTC ms_mod = Main, ms_textual_imps = [(Nothing, Prelude)] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file bug.hs *** Checking old interface for Main (use -ddump-hi-diffs for more details): [1 of 1] Compiling Main ( bug.hs, bug.o ) *** Parser [Main]: !!! Parser [Main]: finished in 0.13 milliseconds, allocated 0.090 megabytes *** Renamer/typechecker [Main]: *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): repSplitAppTys a_anL[sk:1] b_anM[sk:1] [] 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/types/Type.hs:808:9 in ghc:Type }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14568> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs
by GHC 08 Dec '17

08 Dec '17

#14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 System | Keywords: gdb, | Operating System: Unknown/Multiple debugging | Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #9706 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.0.2 on Linux changed the memory allocator to always allocate 1TB virtual memory on startup (#9706). I now have a production Haskell program running in a loop and would like to debug where it is stuck, on another machine, thus attaching with `gdb -p` and running `generate-core-file`. But core dumping takes forever, I Ctrl-C'd it when it reached 140 GB in size (my machine only has 64 GB RAM btw.); after the Ctrl-C the size of the core file on the file system was reported as `1.1T` (probably it's a sparse file now). Is there a workaround for this? For example, if I could dump only the resident or actually allocated pages, that would probably help. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14192> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

Re: [GHC] #440: parse error way too late
by GHC 08 Dec '17

08 Dec '17

#440: parse error way too late -------------------------------------+-------------------- Reporter: as49 | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.2.2 Resolution: None | Keywords: Type of failure: None/Unknown | -------------------------------------+-------------------- Changes (by Ben Gamari <ben@…>): * failure: => None/Unknown Comment: In [changeset:"7733e44dd4ba7e7a0a9f3456e6ddc32decbcf5a3/ghc" 7733e44d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7733e44dd4ba7e7a0a9f3456e6ddc32decbcf5a3" Rip out hadrian subtree Sadly subtrees haven't worked quite as well as we would have liked for developers. See Hadrian #440. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/440#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0