February 2016 - ghc-tickets

[GHC] #11552: ScopedTypeVariables / InstanceSigs do not work in GHC 8.0
by GHC 08 Feb '16

08 Feb '16

#11552: ScopedTypeVariables / InstanceSigs do not work in GHC 8.0 -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE ScopedTypeVariables #-} module MyMaybeT where newtype MaybeT m a = MaybeT { runMaybeT :: m (Maybe a) } instance (Functor m) => Functor (MaybeT m) where fmap f (MaybeT ma) = MaybeT $ (fmap . fmap) f ma instance forall f . (Applicative f) => Applicative (MaybeT f) where pure :: a -> MaybeT f a pure x = MaybeT (pure (pure x)) (<*>) :: forall a b . Applicative f => MaybeT f (a -> b) -> MaybeT f a -> MaybeT f b (MaybeT fab) <*> (MaybeT mma) = let fab' :: f (Maybe (a -> b)) fab' = fab in MaybeT $ undefined }}} Works fine in 7.10.3, breaks in GHC 8.0: {{{ Prelude> :l code/myMaybeT1.hs [1 of 1] Compiling MyMaybeT ( code/myMaybeT1.hs, interpreted ) code/myMaybeT1.hs:13:10: error: Malformed instance: forall f. (Applicative f) => Applicative (MaybeT f) code/myMaybeT1.hs:14:3: error: The class method signature for ‘pure’ lacks an accompanying binding (The class method signature must be given where ‘pure’ is declared) code/myMaybeT1.hs:17:3: error: The class method signature for ‘<*>’ lacks an accompanying binding (The class method signature must be given where ‘<*>’ is declared) code/myMaybeT1.hs:17:37: error: Not in scope: type variable ‘f’ code/myMaybeT1.hs:17:49: error: Not in scope: type variable ‘f’ code/myMaybeT1.hs:17:70: error: Not in scope: type variable ‘f’ code/myMaybeT1.hs:17:84: error: Not in scope: type variable ‘f’ Failed, modules loaded: none. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11552> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11163: New exhaustiveness checker breaks T5642
by GHC 08 Feb '16

08 Feb '16

#11163: New exhaustiveness checker breaks T5642 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The new exhaustiveness checker drastically increases compile time of the `T5642` testcase. From the profile it appears that a great deal of time is being spent evaluating `Check.mkPmId.occname`, {{{ COST CENTRE MODULE %time %alloc mkPmId.occname Check 73.7 16.9 mkOneConFull Check 3.4 10.2 deSugar HscMain 2.8 14.8 mkOneConFull.arguments Check 2.5 5.5 pmTraverse Check 1.6 0.8 mkOneConFull.subst1 Check 1.5 5.9 wrapK.go Check 1.5 5.9 cMatcher Check 1.2 2.7 canEvVar TcCanonical 1.0 3.4 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11163> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11161: New exhaustiveness checker breaks concurrent/prog001
by GHC 08 Feb '16

08 Feb '16

#11161: New exhaustiveness checker breaks concurrent/prog001 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: concurrent/prog001 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The new exhaustiveness checker appears to allocate until the machine runs out of memory while compiling the `concurrent/prog001` testcase. In particular it stalls while desugaring the `Thread` module. The fact that this module contains non-trivial pattern matching, coupled with the compiler gets stuck in `Desugar`, and the fact that I've noted other performance issues with the new exhaustiveness checker (see #10711) leads me to believe that this patch is to blame. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11161> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11160: New exhaustiveness checker breaks ghcirun004
by GHC 08 Feb '16

08 Feb '16

#11160: New exhaustiveness checker breaks ghcirun004 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The new exhaustiveness checker has broken `tests/ghci/should_run/ghcirun004`, which now hangs in desugaring. If one removes all but a few hundred of `foo`'s equations in the test things return to sanity. It appears that the compile time is scaling non-linearly with the number of equations, ||= no. equations =||= compile wall time =|| || 150 || 0.4 s || || 250 || 0.89 s || || 300 || 1.22 s || || 350 || 1.85 s || || 400 || 2.65 s || || 500 || 4.86 s || || 550 || 6.60 s || || 600 || 8.65 s || || 650 || 10.27 s || || 700 || 12.84 s || || 1000 || 38.51 s || -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11160> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker
by GHC 08 Feb '16

08 Feb '16

#11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- hvr stumbled upon this issue while attempting to bootstrap GHC with GHC HEAD. In so doing he found that GHC HEAD required more than 10 GB of memory while compiling `genprimopcode` (and never completed). It appears that this blow-up is due to the new pattern checker. In particular it appears that the pattern checker is affected quite adversely by sets of patterns sharing a prefix. For instance, this example, {{{#!hs import System.Environment main :: IO () main = do args <- getArgs print $ case head args of "--primop-primop-info" -> "turtle" "--primop-tag" -> "asdf" "--primop-list" -> "casdhf" "--primop-vector-uniques" -> "this" "--primop-vector-tys" -> "is" "--primop-vector-tys-exports" -> "silly" "--primop-vector-tycons" -> "hmmm" "--make-haskell-wrappers" -> "123512" "--make-haskell-source" -> "as;dg" "--make-latex-doc" -> "adghiw" _ -> error "Should not happen, known_args out of sync?" }}} As written GHC requires over ten gigabytes of heap and several minutes to compile the example. If one perform `s/--primop-//` to this example it takes 500ms to compile. Alternatively, if on replace the first `-` in each of the `--primop` strings with a unique character (thus breaking the shared prefixes) compilation time is a bit shy of a second. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11303> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

Re: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled
by GHC 08 Feb '16

08 Feb '16

#11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"a96c4e7ca391ff3003d5debf187e7d177131f2fe/ghc" a96c4e7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a96c4e7ca391ff3003d5debf187e7d177131f2fe" Add comments to TcCoercibleFail Flag up the problem highlighted in Trac #11518 comment:15 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11518#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11556: GHC recompiles unchanged hs-boot files
by GHC 08 Feb '16

08 Feb '16

#11556: GHC recompiles unchanged hs-boot files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11013, #10333 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A.hs: {{{#!hs module A where import B f = someError }}} A.hs-boot: {{{#!hs module A where }}} B.hs: {{{#!hs module B where import {-# SOURCE #-} A }}} {{{ $ ghc-7.10.3 --make A.hs [1 of 3] Compiling A[boot] ( A.hs-boot, A.o-boot ) [2 of 3] Compiling B ( B.hs, B.o ) [3 of 3] Compiling A ( A.hs, A.o ) A.hs:5:5: Not in scope: ‘someError’ $ ghc-7.10.3 --make A.hs [1 of 3] Compiling A[boot] ( A.hs-boot, A.o-boot ) [3 of 3] Compiling A ( A.hs, A.o ) A.hs:5:5: Not in scope: ‘someError’ }}} Why does `ghc --make` recompile `B.hs-boot`? Note that recompilation avoidance does work when using `ghc -c`: {{{ $ ghc -c A.hs-boot compilation IS NOT required }}} (found while trying to reduce the testcase for #11532, which contains 644 .hs and 642 .hs-boot files) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11556> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #4029: ghci leaks memory when loading a file
by GHC 08 Feb '16

08 Feb '16

#4029: ghci leaks memory when loading a file -------------------------------------+------------------------------------- Reporter: blarsen | Owner: jme Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: Resolution: | Keywords: memory leak Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jme): * owner: => jme -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4029#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7482: GHC.Event overwrites main IO managers hooks to RTS
by GHC 07 Feb '16

07 Feb '16

#7482: GHC.Event overwrites main IO managers hooks to RTS -------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.4.1 Resolution: fixed | Keywords: IO Manager, | RTS Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: Re-reading comment:6, I think it's safe to close this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7482#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7625: Semicolon is not handled between imports at the ghci command prompt
by GHC 07 Feb '16

07 Feb '16

#7625: Semicolon is not handled between imports at the ghci command prompt -------------------------------------+------------------------------------- Reporter: JohnWiegley | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.4.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #11392 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #11392 Comment: This is now tracked in #11392. The error message in 8.0 is a little bit nicer at least, after #10663: {{{ Prelude> import Data.List ; import Data.Map error: expecting a single import declaration }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7625#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0