January 2015 - ghc-tickets

[GHC] #8914: Remove unnecessary constraints from MonadComprehensions and ParallelListComp
by GHC 26 May '16

26 May '16

#8914: Remove unnecessary constraints from MonadComprehensions and ParallelListComp -------------------------------------------+------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Difficult (2-5 days) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Many parts of MonadComprehensions don't actually require monads instance, the following could do with a `Functor` constraint {{{ fmapM :: Monad m => (a -> b) -> m a -> m b fmapM f xs = [ f x | x <- xs ] }}} and I don't see any reason why the class `MonadZip` (from [http://hackage.haskell.org/package/base-4.4.0.0/docs/Control-Monad- Zip.html Control.Monad.Zip]) requires a `Monad` constraint rather a `Functor` constraint: {{{ class Functor f => FunctorZip f where fzip :: f a -> f b -> f (a,b) fzip = fzipWith (,) fzipWith :: (a -> b -> c) -> f a -> f b -> f c fzipWith f fa fb = fmap (uncurry f) (fzip fa fb) funzip :: f (a,b) -> (f a, f b) funzip fab = (fmap fst fab, fmap snd fab) }}} with the laws {{{ fmap (f *** g) (fzip fa fb) = fzip (fmap f fa) (fmap g fb) fmap (const ()) fa = fmap (const ()) fb ==> funzip (fzip fa fb) = (fa, fb) }}} Same with `Applicative` (see ApplicativeDo): {{{ liftA2 :: Applicative f => (a -> b -> c) -> f a -> f b -> f c liftA2 f a1 a2 = [ f x1 x2 | x1 <- a1, x2 <- a2 ] }}} The reason I bring this up is because I'm writing a DSL that uses length- indexed vectors whose `Functor` and `FunctorZip` instances are trivial but whose `Monad` instance is [http://stackoverflow.com/questions/5802628 /monad-instance-of-a-number-parameterised-vector complicated] and not need. This proposal shares a similar rationale as ApplicativeDo. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8914> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9526: Add missing Generic instances in base
by GHC 25 May '16

25 May '16

#9526: Add missing Generic instances in base -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: than a day) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Most primitive types (`Int`, `Char`, etc.) have a GHC.Generics.Generic instance, but some are missing, such as `Integer` and the various `Word*` data types. We should consistently have instances for all primitive types offered by base, since they are required if you want to derive a Generic instance for any type that contains them. I boldly set the milestone to 7.10 because I naively assume this should be straightforward. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9526> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8990: Performance tests behave differently depending on presence of .hi file (even with -fforce-recomp)
by GHC 24 May '16

24 May '16

#8990: Performance tests behave differently depending on presence of .hi file (even with -fforce-recomp) ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Example: {{{ [ezyang@hs01 compiler]$ cat T6048.comp.stats /home/hs01/ezyang/ghc-compalloc/inplace/lib/bin/ghc-stage2 -B/home/hs01/ezyang/ghc-compalloc/inplace/lib -fforce-recomp -dno-debug- output -no-user-package-db -rtsopts -fno-ghci-history -c T6048.hs -O -fasm +RTS -V0 -tT6048.comp.stats --machine-readable [("bytes allocated", "119871672") ,("num_GCs", "100") ,("average_bytes_used", "4388904") ,("max_bytes_used", "12539576") ,("num_byte_usage_samples", "7") ,("peak_megabytes_allocated", "27") ,("init_cpu_seconds", "0.00") ,("init_wall_seconds", "0.00") ,("mutator_cpu_seconds", "0.09") ,("mutator_wall_seconds", "0.10") ,("GC_cpu_seconds", "0.15") ,("GC_wall_seconds", "0.15") ] [ezyang@hs01 compiler]$ rm T6048.hi [ezyang@hs01 compiler]$ '/home/hs01/ezyang/ghc-compalloc/inplace/bin/ghc- stage2' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T6048.hs -O -fasm +RTS -V0 -tT6048.comp.stats --machine-readable -RTS [ezyang@hs01 compiler]$ cat T6048.comp.stats /home/hs01/ezyang/ghc-compalloc/inplace/lib/bin/ghc-stage2 -B/home/hs01/ezyang/ghc-compalloc/inplace/lib -fforce-recomp -dno-debug- output -no-user-package-db -rtsopts -fno-ghci-history -c T6048.hs -O -fasm +RTS -V0 -tT6048.comp.stats --machine-readable [("bytes allocated", "121022912") ,("num_GCs", "100") ,("average_bytes_used", "4022069") ,("max_bytes_used", "11224944") ,("num_byte_usage_samples", "7") ,("peak_megabytes_allocated", "25") ,("init_cpu_seconds", "0.00") ,("init_wall_seconds", "0.00") ,("mutator_cpu_seconds", "0.09") ,("mutator_wall_seconds", "0.11") ,("GC_cpu_seconds", "0.15") ,("GC_wall_seconds", "0.14") ] }}} It's a slight but present difference: I noticed because one of the perf tests was failing on an initial run of the test suite, but passing when I re-ran it. There are two possible bugs here. One is that our implementation of `-fforce-recomp` is buggy and we shouldn't be reading in the hi file at all if `-fforce-recomp` is on; the other is that we should always clean up interface files before running one of these perf tests. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8990> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9095: make sdist picks up test files
by GHC 22 May '16

22 May '16

#9095: make sdist picks up test files ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I recently ran 'make sdist' and discovered that I my source tarball was nearly a gigabyte large. Closer inspection revealed that sdist had slurped up executable files for tests that I had run at some point. It would be preferable if 'make sdist' did not do that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9095> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9298: ghc.exe: internal error: evacuate: strange closure type 365488164
by GHC 21 May '16

21 May '16

#9298: ghc.exe: internal error: evacuate: strange closure type 365488164 ------------------------------+--------------------------------------- Reporter: Tominator2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: idris | Operating System: Windows Architecture: x86 | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------+--------------------------------------- after saying "cabal install idris" the machine churned for a while, spitting out messages, then said: src\Idris\AbsSyntax.hs:1569:10: Warning: `EitherErr' is an instance of Monad but not Applicative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. ghc.exe: internal error: evacuate: strange closure type 365488164 (GHC version 7.8.2 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Failed to install idris-0.9.13.1 cabal.exe: Error: some packages failed to install: idris-0.9.13.1 failed during the building phase. The exception was: ExitFailure 3 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9298> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9059: Excessive space usage while generating code for fractional literals with big exponents
by GHC 19 May '16

19 May '16

#9059: Excessive space usage while generating code for fractional literals with big exponents ------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Generating (byte-)code for fractional literals with big exponents causes excessive space usage: {{{ $ ghci -ddump-bcos GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> let r=1e1000 :: Rational ==================== Proto-BCOs ==================== ProtoBCO ExprTopLevel_E0#0 []: let sat_so4 = ... in ... bitmap: 0 [] ALLOC_AP 0 PUSH_BCO ProtoBCO sat_so4#0 []: let sat_snX = ... in ... bitmap: 0 [] PUSH_UBX (1) 1 PACK GHC.Integer.Type.S# 1 ALLOC_AP 0 PUSH_BCO ProtoBCO sat_snY#0 []: let sat_siH = ... in ... bitmap: 0 [] STKCHECK 544 PUSH_UBX (1) 30 PACK GHC.Types.I# 1 PUSH_G GHC.Types.[] PUSH_L 1 PACK : 2 PUSH_UBX (1) 953884573 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 1777164331 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 1665817172 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 1937337765 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 799142572 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 1439062260 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 1049546550 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 580758741 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 139570364 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 ... }}} Increasing the exponent to say a 1000000 will quickly fill up the memory of my machine. A similar problem occurs while compiling: !BigExponentBug.hs: {{{ module BigExponentBug (r) where r = 1e100 :: Rational }}} {{{ ghc --make BigExponentBug.hs -ddump-simpl [1 of 1] Compiling BigExponentBug ( BigExponentBug.hs, BigExponentBug.o ) ==================== Tidy Core ==================== Result size of Tidy Core = {terms: 9, types: 5, coercions: 0} BigExponentBug.r :: GHC.Real.Rational [GblId] BigExponentBug.r = GHC.Real.fromRational @ GHC.Real.Rational (GHC.Real.$fFractionalRatio @ GHC.Integer.Type.Integer (GHC.Real.$fNumRatio @ GHC.Integer.Type.Integer GHC.Real.$fIntegralInteger) GHC.Real.$fIntegralInteger) (GHC.Real.:% @ GHC.Integer.Type.Integer (__integer 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000) (__integer 1)) }}} Again increasing the exponent to 1000000 quickly invokes the OOM killer on my machine. P.S. This bug was discovered while fixing a [https://github.com/bos/aeson/issues/198 related bug] in `aeson`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9059> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8207: Show instance for Language in DynFlags
by GHC 17 May '16

17 May '16

#8207: Show instance for Language in DynFlags ------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: GHC API | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I feel that the GHC API could benefit from a Show instance for Language in DynFlags.hs. Currently, if we want to display the language being used we have to do something like {{{ foo inf = case hmi_language inf of Nothing -> Nothing Just Haskell98 -> Just "Haskell98" Just Haskell2010 -> Just "Haskell2010" }}} This is pretty much just the Show instance (over Maybe) and Haskell can derive it for us automatically: we just need to change `deriving Enum` to `deriving (Enum, Show)`. The above solution is not the most robust ever as if this data type is ever changed, this starts to form an incomplete pattern. If we have a catch all `_`, GHC complains about overlapping patterns. Easily solved with `show <$> hmi_language inf`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8207> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9478: Partial type signatures
by GHC 10 May '16

10 May '16

#9478: Partial type signatures -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D168 -------------------------------------+------------------------------------- This ticket tracks progress on '''partial type signatures'''. * Wiki page [wiki:PartialTypeSignatures] * Phabricator link: Phab:D168 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9478> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8865: Cannot derive well-kinded instance of form ‘Category
by GHC 02 May '16

02 May '16

#8865: Cannot derive well-kinded instance of form ‘Category ----------------------------+---------------------------------------------- Reporter: | Owner: adinapoli | Status: new Type: bug | Milestone: 7.8.1 Priority: normal | Version: 7.8.1-rc2 Component: Compiler | Operating System: MacOS X Keywords: | Type of failure: GHC rejects valid program Architecture: x86_64 | Test Case: (amd64) | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Hello everyone, sorry if this was already reported somewhere. I'm playing with GHC 7.8.1 RC2 and I'm updating hsenv to support GHC 7.8. This is a real code snippet, which was compiling fine in GHC 7.6.x {{{ newtype ArgArrow a b = ArgArrow (StaticArrowT KnownArgs (Kleisli (ReaderT Args IO)) a b) deriving (Category, Arrow, ArrowChoice) }}} but that yields the following in GHC 7.8.1-RC2 {{{ Cannot derive well-kinded instance of form ‘Category (ArgArrow ...)’ Class ‘Category’ expects an argument of kind ‘k -> k -> *’ In the newtype declaration for ‘ArgArrow’ }}} This might be related to the new feature of GHC 7.8, namely "kind variables" (you get the idea, even if the name is not 100% accurate). To make the code compile I had to enable {{{ StandaloneDeriving }}} and write the following: {{{ newtype ArgArrow a b = ArgArrow (StaticArrowT KnownArgs (Kleisli (ReaderT Args IO)) a b) deriving (Arrow, ArrowChoice) deriving instance Category ArgArrow }}} Is this by design or is a genuine bug? Thanks! Alfredo -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8865> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9758: By default, testsuite should clean up after successful tests
by GHC 30 Apr '16

30 Apr '16

#9758: By default, testsuite should clean up after successful tests -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: low | Milestone: Component: Test Suite | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- A fully built GHC compiler for development takes about 1G of space. However, running the testsuite balloons this amount to 10G. Why? Because we don't clear away any test files by default. Now, it's pretty useful to have these files if you're debugging a problem. But I think it's pretty unnecessary for successful tests. So I suggest cleaning out the files automatically if the test succeeds. Tradeoff: the testsuite will take longer to run since it is cleaning up after itself. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9758> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5