May 2015 - ghc-tickets

[GHC] #9851: Hoopl library in GHC hides runWithFuel / version number clash
by GHC 05 May '15

05 May '15

#9851: Hoopl library in GHC hides runWithFuel / version number clash -------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/hoopl | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The hoopl library on hackage exposes runWithFuel in Compiler.Hoopl. This function is used in the examples distributed with the library (in the testing directory). The version of hoopl distributed in GHC does not expose runWithFuel. Further, the version number of the GHC packaged hoopl is identical to the version number of the hoopl library on hackage. This is (1) confusing, since the haddock docs on hackage for the version in use on the system by default is not accurate, and (2) annoying, since you cannot get the version on hackage by just running a cabal install. Instead, you have to download the package, update the version number, and then cabal install. The fix seems to involve one or both of the following: (1) Bump the version number of hoopl on hackage. (2) Expose runWithFuel in the version distributed with GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9851> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #3046: Generalized newtype deriving with associated types
by GHC 05 May '15

05 May '15

#3046: Generalized newtype deriving with associated types -------------------------------------+------------------------------------- Reporter: LouisWasserman | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Correct; #8165 is the relevant ticket, and has a good discussion string. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3046#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10108: Dramatic slowdown with -O2 bytestream and list streams combined.
by GHC 05 May '15

05 May '15

#10108: Dramatic slowdown with -O2 bytestream and list streams combined. -------------------------------------+------------------------------------- Reporter: Truman | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Linux Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: break_in.hs | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In a small testcase intended to filter log files from stdin, I found that using bytestreams and list streams in combination worked fine when compiled without optimization, but runtime performance slowed down by a factor of about 3600 when I compiled with -O2. Changing the import of Data.List.Stream to Data.List gets rid of the problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10108> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9530: min / max do not always return a NaN when one of the arguments is NaN
by GHC 04 May '15

04 May '15

#9530: min / max do not always return a NaN when one of the arguments is NaN -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Incorrect Difficulty: Easy (less than 1 | result at runtime hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- I assume that this is well-known, but it tripped me up: {{{ Prelude> let inf = 1/0 Prelude> let nan = 0/0 Prelude> min nan inf Infinity Prelude> min inf nan NaN Prelude> min 3 nan NaN Prelude> min nan 3 3.0 Prelude> max nan inf NaN Prelude> max inf nan Infinity Prelude> max 3 nan 3.0 Prelude> max nan 3 NaN }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9530> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10381: Type-checking failure with RankNTypes and RebindableSyntax
by GHC 04 May '15

04 May '15

#10381: Type-checking failure with RankNTypes and RebindableSyntax -------------------------------------+------------------------------------- Reporter: goldfire | 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: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE RebindableSyntax, RankNTypes #-} module Bug where import Prelude ( String, undefined ) newtype Cont r a = Cont { runCont :: (forall i. a i -> r) -> r } (>>=) :: Cont r a -> (forall i. a i -> Cont r b) -> Cont r b ma >>= fmb = Cont (\k -> runCont ma (\a -> runCont (fmb a) k)) fail :: String -> Cont r a fail = undefined return :: a i -> Cont r a return x = Cont (\k -> k x) foo :: Cont r [] foo = do bar <- foo return bar }}} I get {{{ Bug.hs:21:3: Couldn't match type ‘i0’ with ‘i’ because type variable ‘i’ would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: [i] -> Cont r [] at Bug.hs:21:3-12 Expected type: Cont r [] -> ([i0] -> Cont r []) -> Cont r [] Actual type: Cont r [] -> (forall i. [i] -> Cont r []) -> Cont r [] In a stmt of a 'do' block: bar <- foo In the expression: do { bar <- foo; return bar } In an equation for ‘foo’: foo = do { bar <- foo; return bar } }}} Yet, {{{ baz :: Cont r [] baz = baz >>= \bar -> return bar }}} at the end of this file compiles just fine. I had thought that `foo` and `baz` are entirely equivalent. Note that, with normal `do` notation, it ''is'' possible to do a GADT-like pattern-match with `<-`, without anyone's brain exploding. Some background: I'm attempting to write a type-checker for a simply-typed lambda calculus that uses GADTs to help me write the evaluation functions. The actual lambda-calculus bit has gone swimmingly; you can see it [https://github.com/goldfirere/glambda/blob/master/Language/Glambda/Exp.hs here]. But now I'm writing a type-checker, which has to take a possibly- ill-typed expression of type `UExp` and convert it to an `Exp ctx ty`, which is guaranteed to have type `ty` in context (a list of types) `ctx`. I can't just write {{{ check :: UExp -> Maybe (Exp '[] ty) }}} because the type has to be an ''output''. I could use existentials, but I find continuation-passing style to be easier to work with. But then the syntax goes all terrible. So, I want the `Cont` monad. Except that doesn't deal with these existentially-bound type variables at all. And, without doing any category theory, I have a very strong hunch that my CPS-with- extra-type-variables does not form a Monad. But, no matter, I'll just use `RebindableSyntax` and define my enhanced `Cont` not-a-monad with appropriate operators, and get my nice syntax back. But it doesn't work, as we see with this ticket. :( Clearly, this isn't really blocking me, but it makes me a touch sad not to use the nice syntax. `foo` fails to type-check in both 7.8 and 7.10, although the error messages are quite different (7.10 is an improvement). `baz` type-checks in both. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10381> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10306: Calling reify on Any or built-in type families causes panic
by GHC 04 May '15

04 May '15

#10306: Calling reify on Any or built-in type families causes panic -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: #9840 Differential Revisions: Phab:D841 | -------------------------------------+------------------------------------- Both `reify ''Any` and `reify ''(+)` (where `(+)` is the built-in operation on type-level naturals) result in a panic `TcSplice.reifyFamFlavour: not a type family`. I came across this while working on #9840 and have a fix as part of Phab:D841. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10306> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #8028: Panic on degenerate closed type family
by GHC 04 May '15

04 May '15

#8028: Panic on degenerate closed type family -------------------------------------------------+------------------------- Reporter: monoidal | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------------------+------------------------- Comment (by Adam Gundry <adam@…>): In [changeset:"4efa421327cf127ebefde59b2eece693e37dc3c6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4efa421327cf127ebefde59b2eece693e37dc3c6" Permit empty closed type families Fixes #9840 and #10306, and includes an alternative resolution to #8028. This permits empty closed type families, and documents them in the user guide. It updates the Haddock submodule to support the API change. Test Plan: Added `indexed-types/should_compile/T9840` and updated `indexed-types/should_fail/ClosedFam4` and `th/T8028`. Reviewers: austin, simonpj, goldfire Reviewed By: goldfire Subscribers: bgamari, jstolarek, thomie, goldfire Differential Revision: https://phabricator.haskell.org/D841 GHC Trac Issues: #9840, #10306 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8028#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7452: [GNU gold] ld: error: cannot find [...]/Types__1.o
by GHC 04 May '15

04 May '15

#7452: [GNU gold] ld: error: cannot find [...]/Types__1.o -------------------------------------+------------------------------------- Reporter: mrothe | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7452#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8941: Module that causes GHC-7.8 to exhaust memory compiled with -O2
by GHC 04 May '15

04 May '15

#8941: Module that causes GHC-7.8 to exhaust memory compiled with -O2 ------------------------------------+--------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- The module is JSON.Render in http://src.seereason.com/o2bug. When compiled ghc uses up at least 16GB of RAM and then dies. I haven't been able to simplify it very much, almost any change to JSON.Render causes it to start working properly. I did get it to fail using only packages available in hackage. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8941> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8086: Minimal install for GHC
by GHC 04 May '15

04 May '15

#8086: Minimal install for GHC ------------------------------------+--------------------------------- Reporter: gidyn | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- Installing GHC on a shared server requires a minimal footprint, without GHCi, profiling, debugging, documentation, or anything else not needed for regular building and installing. And anything stripable should be striped, if it isn't already. It would be great if the configuration script would support a --minimal option. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8086> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3