- ghc-tickets - Haskell.org

[GHC] #16172: GHC 8.4 build failure on ARM
by GHC 12 Jan '19

12 Jan '19

#16172: GHC 8.4 build failure on ARM --------------------------------+---------------------------------------- Reporter: dustin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- Using the same environment I used to build 8.6 and got the following error: {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.4.4.20181014 for arm-unknown-linux): padLiveArgs -- i > regNum ?? CallStack (from HasCallStack): error, called at compiler/llvmGen/LlvmCodeGen/Base.hs:194:27 in ghc:LlvmCodeGen.Base Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug rts/ghc.mk:295: recipe for target 'rts/dist/build/HeapStackCheck.o' failed make[1]: *** [rts/dist/build/HeapStackCheck.o] Error 1 make[1]: *** Waiting for unfinished jobs.... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16172> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16171: "ApplicativeDo" disables -Wunused-do-binds?
by GHC 12 Jan '19

12 Jan '19

#16171: "ApplicativeDo" disables -Wunused-do-binds? -------------------------------------+------------------------------------- Reporter: eschnett | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- In the code below, the return value of {{{forkIO}}} is ignored. The compiler fails to not warn about this. When I disable the {{{ApplicativeDo}}} extension, the warning appears as expected. {{{ {-# OPTIONS_GHC -Wall #-} {-# LANGUAGE ApplicativeDo #-} module Example (main) where import Control.Concurrent main :: IO () main = do x <- return () forkIO (putStrLn "hello") putStrLn $ "world" ++ show x }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16171> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16163: Don’t throw an error (by default) for use of DEPRECATED symbols under -Werror
by GHC 12 Jan '19

12 Jan '19

#16163: Don’t throw an error (by default) for use of DEPRECATED symbols under -Werror -------------------------------------+------------------------------------- Reporter: m-renaud | 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: -------------------------------------+------------------------------------- = Summary == Overview Don’t throw an error by default under `-Werror` when a `DEPRECATED` module, function, or type is imported or used. Use or import of a module, function, or type marked with the `WARNING` pragma will still be promoted to an error under `-Werror`. == The Idea Some “warnings” are more what you would consider “information” not and should not be considered “errors” under `-Werror` (unless explicitly requested). == Motivation Consider you’re the maintainer of a widely used library and you wish to remove some function in some later release. There is currently no way of communicating to users of your library that you plan to remove this symbol in some later major release. The natural way to express this would be to add a `DEPRECATED` pragma to the function in the next minor release, leave it there for some time horizon, and then in a following major release remove the symbol. This currently is not practical because a very large number of projects that use your library compile with `-Werror` which will then cause builds to fail //simply because you tried to alert your users of future plans//. I posit that this is broken, the crux of this is that a `DEPRECATED` //should// be considered as //info// and not a true //warning//. As it stands today, **two major releases** are required to safely deprecate (and remove) part of a public API due to the wide usage of `-Werror` which causes build failures when a new DEPRECATED pragma is added. The first major release adds the DEPRECATED pragma and the second removed the symbol or module. This discourages deprecating old APIs, introduces unnecessary version churn, and makes it more difficult to communicate to consumers of a library that an upcoming release will remove a feature. As a specific example, when attempting to align the public APIs of `containers` and `unordered-containers` (renaming `HashMap.lookupDefault` to `HashMap.findWithDefault` to match the API of `containers`) the largest issue was how to actually deprecate the old function. The `unordered- containers` API is relatively stable and it wouldn’t warrant a new major version just to mark a function as `DEPRECATED`. You can see the discussion here (http://haskell.1045720.n5.nabble.com/Proposal-Rename- HashMap-lookupDefault-to-HashMap-findWithDefault-td5870348.html). = Changes == Flag Changes **Before** `-Wdeprecations` - warn if a module, function, or type marked `DEPRECATED` or `WARNING` is imported or used. `-Wwarnings-deprecations` - warn if a module, function, or type marked `DEPRECATED` or `WARNING` is imported or used. (The name of this flag is unfortunate, imho it should be named `-Wwarnings`) `-Werror` - promote warnings to errors, including both `-Wdeprecations` and `-Wwarnings`. In other words, if a `DEPRECATED` or `WARNING` module, function, or type is imported or used. Note that //currently// there is **no distinction** between things marked as `WARNING` and things marked as `DEPRECATED` at the flag level, this is problematic. **After** `-Wdeprecations` - warn if a module, function, or type marked `DEPRECATED` is imported or used. `-Wwarnings-deprecations` (or rename to `-Wwarnings`) - warn if a function, module, or type marked `WARNING` is imported or used. `-Werror` - promote warnings to errors, including `-Wwarnings- deprecations` (`WARNING`), **but not** `-Wdeprecations` (`DEPRECATED`). (optional) `-Wwarnings` - warn if a function, module, or type marked `WARNING` is imported or used. This is a clearer flag name than `-Wwarnings-deprecations`. == Precedent for excluding warnings from being promoted to errors The idea that some things considered “warnings” are not actually “errors” already exists, specifically the flag `-Wmissed-specialisations` (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/using- warnings.html#ghc-flag--Wmissed-specialisations) is already excluded from the set of warnings that are not considered as errors. == How do I get the old behaviour back? aka. treat DEPRECATED as an error If you’re using a library and you’d like to be extra up to date and cause your build to fail if you’re using a deprecated function then you can pass `-Werror=deprecations` to GHC and it will treat use of `DEPRECATED` as an error. = Alternatives Considered == No change (baseline) The current state of the world as discussed in the //Motivation// section causes real issues related to natural evolution of APIs. I feel that this is not desirable in the long term. == Ask people to exclude `DEPRECATED` from `-Werror` Another option is to ask folks to not treat deprecations as errors by explicitly passing `-Wwarn=deprecations` (still requires changes to GHC since `WARNING` and `DEPRECATED` are grouped together currently). This would “fix” the problem but makes the assumption that everyone updates their build flags appropriately which is an incredibly unreasonable assumption. It also doesn’t actually address the core problem of use of deprecated APIs being treated as erroneous. = Related Work/Proposals There is an open PR to the PVP to no longer require a major version bump when a `DEPRECATED` pragma is added which has received support from both the community and members of the CLC (https://github.com/haskell/pvp/pull/18) and follows the same reasoning as here, namely that deprecating something is not meant to (and should not) break anything since it doesn’t change the API, it simply provides some information to users of the library. = Example Implementation I've put together a possible implementation of this at https://gitlab.haskell.org/ghc/ghc/merge_requests/89, but please do not comment on design there, keep that in the trac issue here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16163> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10271: Typed Template Haskell splice difficulty when resolving overloading
by GHC 11 Jan '19

11 Jan '19

#10271: Typed Template Haskell splice difficulty when resolving overloading -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- J Garrett Morris describes the following surprising behaviour for typed Template Haskell {{{ {-# LANGUAGE TemplateHaskell, FlexibleInstances #-} module PrintfLib where import Language.Haskell.TH class Printf t where printf :: String -> Q (TExp String) -> Q (TExp t) instance Printf [Char] where tf s t | '%' `notElem` s = [|| $$t ++ s ||] | otherwise = fail ("Unexpected format %" ++ [c]) where (_, _:c:_) = break ('%' ==) s instance Printf t => Printf (Char -> t) where printf s t | c /= 'c' = fail ("Unexpected format %" ++ [c] ++ " for character") | otherwise = [|| \c -> $$(printf s'' [|| $$t ++ s' ++ [c] ||]) ||] where (s', '%':c:s'') = break ('%' ==) s ------------------------- {-# LANGUAGE TemplateHaskell #-} module Printf where import PrintfLib f :: Char -> String f = $$(printf "foo %c" [||""||]) h :: Char -> String h y = $$(printf "foo %c" [||""||]) y }}} Oddly, `f` typechecks but `h` does not, even though `h` is just an eta- expanded version of `f`: {{{ Printf.hs:9:10: No instance for (Printf t0) arising from a use of ‘printf’ The type variable ‘t0’ is ambiguous Note: there are several potential instances: instance Printf t => Printf (Char -> t) -- Defined in ‘PrintfLib’ instance Printf [Char] -- Defined in ‘PrintfLib’ In the expression: printf "foo %c" [|| "" ||] }}} What is going on? Here's the deal * To run the splice, GHC must solve any constraints that arise form the expression `(printf "foo %c" ...)`. * Since `printf` is overloaded, and overloaded on its result type, the type needed by the context of the splice is what determines which instance of `Printf` is needed. * In `f` the context needs `Char -> String`, and so the call to `printf` must have type `TExpr (Char -> String)`, so we get the constraint `Printf (Char -> String)` which we can solve. * But in `h` the rule for application tries to ''infer'' a type for the splice. So the context for the call just says `TExp t0` for some unification variable `t0`; and that leads to the insoluble constraint. You may say that GHC should be cleverer, and push that type signature information into the application. And perhaps it should. But you can never win. For example: {{{ hard x = [ $$(printf "gluk" [|| "" ||]), undefined :: Char -> String ] }}} Here the RHS of `hard` is a 2-element list. Since all elements of a list have the same type, the splice must have the same type as the second element of the list, namely `Char->String`. But seeing that would mean that we'd have to typecheck right-to-left. In general GHC tries very very hard NOT to depend on traveral order. There is no way in general to ensure that we have all the information now that constraint solving may ultimately produce. I'm not sure what to do about this. * It seldom matters, because resolving the overloading on the splice seldom depends on the result type. * When it does matter, you can fix it by giving a type signature to the splice itself. But it seems unsatisfactory. Ideas welcome. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10271> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16170: Regression for #15806: -hT not available when profiling
by GHC 11 Jan '19

11 Jan '19

#16170: Regression for #15806: -hT not available when profiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: 15806 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- 9 months ago, I opened #15806, which was about documenting when -hT can be used. Ben created some patches to resolve this, but with GHC 8.6.3, I find the behavior is identical to 8.4.2, namely: * -hT is disallowed for executables built with profiling * the docs make no mention of this * when profiling is enabled, the list of options for heap profiling make no mention of -hT, making me question my sanity. Ben apparently fixed all of these, but perhaps it never got merged? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16170> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12488: Explicit namespaces doesn't enforce namespaces
by GHC 11 Jan '19

11 Jan '19

#12488: Explicit namespaces doesn't enforce namespaces -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems to me that the type keyword should permanently enforce that a RdrName lives in a particular namespace. Currently it only acts as a syntactic marker so that type constructors which looks like variables can be included in export lists. The following example is accepted by GHC. As `A` is parsed as a type constructor but later put into the data constructor namespace. {{{#!hs {-# LANGUAGE ExplicitNamespaces #-} {-# LANGUAGE TypeFamilies #-} module M ( T (type A) ) where data T = A class Foo a where type A a foo :: a -> Int }}} The fix is to track uses of ExplicitNamespaces in the AST and then use this information in the renamer. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12488> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11610: Remove IEThingAll constructor from IE datatype
by GHC 11 Jan '19

11 Jan '19

#11610: Remove IEThingAll constructor from IE datatype -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- It seems that now `IEThingWith` can include a wildcard that the `IEThingAll` constructor is a special case. I'm not sure how involved this would be but it seems worth doing. {{{ | IEThingAll (Located name) -- ^ Class/Type plus all methods/constructors -- -- - 'ApiAnnotation.AnnKeywordId's : 'ApiAnnotation.AnnOpen', -- 'ApiAnnotation.AnnDotdot','ApiAnnotation.AnnClose', -- 'ApiAnnotation.AnnType' -- For details on above see note [Api annotations] in ApiAnnotation -- See Note [Located RdrNames] in HsExpr | IEThingWith (Located name) IEWildcard [Located name] [Located (FieldLbl name)] -- ^ Class/Type plus some methods/constructors -- and record fields; see Note [IEThingWith] -- - 'ApiAnnotation.AnnKeywordId's : 'ApiAnnotation.AnnOpen', -- 'ApiAnnotation.AnnClose', -- 'ApiAnnotation.AnnComma', -- 'ApiAnnotation.AnnType' -- For details on above see note [Api annotations] in ApiAnnotation }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11610> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15835: Internal error when splicing value constructed using typed template haskell
by GHC 11 Jan '19

11 Jan '19

#15835: Internal error when splicing value constructed using typed template haskell -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Related to #15833 Compiling Test.hs leads to an internal compiler error. https://gist.github.com/f04a613bb5e20c241c5b91c2f38b8f06 {{{ {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Test where import qualified Compiler as C main :: IO () main = do $$(C.runQuery) }}} {{{ {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# OPTIONS_GHC -Wall #-} module Compiler where import Language.Haskell.TH type QTExp a = Q (TExp a) fix :: (a -> a) -> a fix f = let x = f x in x while :: forall m . Monoid m => QTExp (IO m -> IO m) -> QTExp (IO m) while b = [|| fix (\r -> whenM @(IO m) ($$b r)) ||] whenM :: Monoid m => m -> m whenM _ = mempty execOp :: forall m . Monoid m => QTExp (IO m) execOp = while [|| \r -> $$(while @m [|| id ||]) >> r ||] runQuery :: QTExp (IO ()) runQuery = execOp }}} Leads to the following internal errors even though `Compiler` type checked. {{{ Prelude> :r [1 of 2] Compiling Compiler ( Compiler.hs, interpreted ) [2 of 2] Compiling Test ( Test.hs, interpreted ) Test.hs:9:6-15: Splicing expression C.runQuery ======> C.fix (\ r_a7K7 -> (C.whenM @(IO m_a7Gp)) ((\ r_a7K8 -> ((C.fix (\ r_a7K9 -> (C.whenM @(IO m_a7Gp)) (id r_a7K9))) >> r_a7K8)) r_a7K7)) Test.hs:9:6: error: • The exact Name ‘m’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful • In the result of the splice: $C.runQuery To see what the splice expanded to, use -ddump-splices In the Template Haskell splice $$(C.runQuery) In a stmt of a 'do' block: $$(C.runQuery) | 9 | $$(C.runQuery) | ^^^^^^^^^^ Test.hs:9:6: error: • The exact Name ‘m’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful • In the result of the splice: $C.runQuery To see what the splice expanded to, use -ddump-splices In the Template Haskell splice $$(C.runQuery) In a stmt of a 'do' block: $$(C.runQuery) | 9 | $$(C.runQuery) | ^^^^^^^^^^ Test.hs:9:6: error: • GHC internal error: ‘m’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [a7K7 :-> Identifier[r_a7K7::a0, NotLetBound], r5Fg :-> Identifier[main::IO (), TopLevelLet [] True]] • In the first argument of ‘IO’, namely ‘m’ In the type ‘(IO m)’ In the expression: (C.whenM @(IO m)) ((\ r_a7K8 -> ((C.fix (\ r_a7K9 -> (C.whenM @(IO m)) (id r_a7K9))) >> r_a7K8)) r_a7K7) | 9 | $$(C.runQuery) | }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15835> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13587: addTopDecls fails with typed Template Haskell
by GHC 11 Jan '19

11 Jan '19

#13587: addTopDecls fails with typed Template Haskell -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.2.1-rc1 Haskell | 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 untyped Template Haskell works as expected: {{{#!hs --- AddTopDecls.hs --- {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE QuasiQuotes #-} module AddTopDecls where import Language.Haskell.TH import Language.Haskell.TH.Syntax importDoubleToDouble :: String -> ExpQ importDoubleToDouble fname = do n <- newName fname d <- forImpD CCall unsafe fname n [t|Double -> Double|] addTopDecls [d] varE n --- Main.hs --- {-# LANGUAGE TemplateHaskell #-} module Main where import AddTopDecls main :: IO () main = do let sin' = $(importDoubleToDouble "sin") cos' = $(importDoubleToDouble "cos") -- print (sin' 0) print (cos' pi) }}} However it fails if I convert to the equivalent typed version: {{{#!hs --- AddTopDecls.hs --- {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE QuasiQuotes #-} module AddTopDecls where import Language.Haskell.TH import Language.Haskell.TH.Syntax importDoubleToDouble :: String -> Q (TExp (Double -> Double)) importDoubleToDouble fname = do n <- newName fname d <- forImpD CCall unsafe fname n [t|Double -> Double|] addTopDecls [d] unsafeTExpCoerce (varE n) --- Main.hs --- {-# LANGUAGE TemplateHaskell #-} module Main where import AddTopDecls main :: IO () main = do let sin' = $$(importDoubleToDouble "sin") cos' = $$(importDoubleToDouble "cos") -- print (sin' 0) print (cos' pi) }}} With the error: {{{ > ghci Main.hs -ddump-splices GHCi, version 8.2.0.20170404: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling AddTopDecls ( AddTopDecls.hs, interpreted ) [2 of 2] Compiling Main ( Main.hs, interpreted ) Main.hs:9:19-44: Splicing expression importDoubleToDouble "sin" ======> sin_a4s2 Main.hs:1:1: Splicing top-level declarations added with addTopDecls ======> foreign import ccall unsafe "sin" Main.sin :: Double -> Double Main.hs:9:19: error: • GHC internal error: ‘sin_a4s2’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [a4dl :-> Identifier[sin'::t1, TopLevelLet [] False], a4dm :-> Identifier[cos'::t1, TopLevelLet [] False], r4cW :-> Identifier[main::IO (), TopLevelLet]] • In the expression: sin_a4s2 In the result of the splice: $importDoubleToDouble "sin" To see what the splice expanded to, use -ddump-splices In the Template Haskell splice $$(importDoubleToDouble "sin") | 9 | let sin' = $$(importDoubleToDouble "sin") | ^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Tested with 7.10.3, 8.0.2, and 8.2.0-rc1. Unfortunately I can't use untyped TH in my real use case, so if you have any suggestions for a workaround that would also be great. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13587> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10946: Typed hole inside typed Template Haskell bracket causes panic
by GHC 11 Jan '19

11 Jan '19

#10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template | Version: 7.10.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- When I say: {{{#!hs m :: a -> a m x = $$([||_||]) }}} I get: {{{ T10946.hs:47:13:ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): No skolem info: a_apJ[sk] }}} This happens both with GHC 7.10.1 and latest HEAD (e2b579e8d77357e8b36f57d15daead101586ac8e). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10946> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19