April 2016 - ghc-tickets

[GHC] #9766: Use TypeLits in the meta-data encoding of GHC.Generics
by GHC 02 Jun '16

02 Jun '16

#9766: Use TypeLits in the meta-data encoding of GHC.Generics -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: 9043 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This ticket serves to track the task of improving the meta-data representation in GHC.Generics as described in the following wiki page: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/GenericDeriving#A… I'm working on this in branch `wip/GenericsMetaData`, and I intend to have it in 7.10. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9766> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11120: Missing type representations
by GHC 29 May '16

29 May '16

#11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE DataKinds #-} module Bug where import Data.Typeable foo = typeRep (Proxy :: Proxy '[]) }}} I get {{{ GHC error in desugarer lookup in Bug: Can't find interface-file declaration for variable tc'[] Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151120 for x86_64-apple-darwin): initDs IOEnv failure }}} And I think there may be more trouble. Below are notes I have written to ghc-devs: ------------------------------ I'm a bit confused by the new handling of `Typeable`. 1. You say (in `Note [Grand plan for Typeable]`) that there is trouble making the `TyCon`/`Module` information for the types in `GHC.Types`. But what precisely goes wrong? I agree that it seems a bit fishy, but I don't actually see the spot where trouble lurks. Did you try this? 2. Even more bizarre would be putting `TyCon`/`Module` info for `GHC.Prim` stuff (I'm thinking about the super-magical `TYPE` from my branch) right in `GHC.Prim`. But still I can't quite articulate what goes wrong. There is no Prim.hi file that would be wonky. And, provided that `GHC.Types` itself doesn't try to solve a `Typeable` constraint, no one would ever notice the weird dependency. I recognize that this means we'd have to build the info somewhere manually in GHC, but I don't think that would be too hard -- and I think easier than the current story around name-mangling just so that you can write the typereps by hand in `Data.Typeable.Internal`. There's also not very many lifted tycons in `GHC.Prim`. I count `TYPE` and `RealWorld`, and that's it. For what it's worth, a weird dependency from `GHC.Prim` to `GHC.Types` actually works in practice. I put `Levity` in `GHC.Types` but `TYPE :: Levity -> TYPE 'Lifted` in `GHC.Prim`. No one complained. 3. Let's assume that we really can't clean up this mess. It still seems that several `TyCon`s are missing from `Data.Typeable.Internal`. Like promoted nil and cons, and `Nat`, and `Symbol`. At the least, we should put a loud comment in the export list of `GHC.Types` saying that everything defined there must be accompanied by a definition in `Data.Typeable.Internal`. 4. `Data.Typeable.Internal` uses `mkGhcTypesTyCon`, which refers to `GHC.Types`. But this function is used also for things from `GHC.Prim`, like `(->)`. Solving `Typeable (->)` works fine. But I'm sure there's trouble lurking here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11120> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 56

[GHC] #11468: testsuite should ignore config files
by GHC 27 May '16

27 May '16

#11468: testsuite should ignore config files -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.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: -------------------------------------+------------------------------------- I always get a few test failures like the following. {{{ =====> T9360a(normal) 1 of 3 [0, 0, 0] cd ./driver && "/Users/gridaphobe/Source/ghc/build/D1805/inplace/test spaces/ghc-stage2" --interactive -e "" </dev/null > T9360a.run.stdout 2> T9360a.run.stderr Actual stderr output differs from expected: --- /dev/null 2016-01-20 16:43:09.000000000 -0800 +++ ./driver/T9360a.run.stderr.normalised 2016-01-20 16:43:09.000000000 -0800 @@ -0,0 +1,11 @@ +cannot satisfy -package pretty-show + (use -v for more information) + +<no location info>: + Could not find module ‘Text.Show.Pretty’ + It is not a module in the current program, or in any known package. + +<interactive>:7:25: + Variable not in scope: ppShow :: a -> String + +<interactive>:1:1: Not in scope: ‘pprint’ \ No newline at end of file Actual stdout output differs from expected: }}} The failure is due to my `~/.ghci` file, which loads a few packages that ghc-head obviously hasn't built. The testsuite should ignore `~/.ghci` and any other user configuration files that might affect ghc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11468> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9224: Add support for binary integer literals
by GHC 27 May '16

27 May '16

#9224: Add support for binary integer literals -------------------------------------------+------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Parser) | Version: Keywords: literals | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Currently, Haskell98/2010 support base-10, base-8 (via `0[oO]`-prefix) and base-16 (via `0[xX]`-prefix) integer literals. I hereby propose to add conditional support for base-2 integers via a `0[bB]`-prefix, controlled via a new `-XBinaryLiterals` language extension flag/pragma. The change to the lexer is trivial (see attached patch), however I'm stuck on the lexer using a 32-bit feature-mask, of which all 32bits are already taken, and I'd need a 33th bit for the `BinaryLiteralsBit` flag. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9224> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9051: Report heap profile data in eventlog
by GHC 27 May '16

27 May '16

#9051: Report heap profile data in eventlog ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | 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: | ------------------------------------+------------------------------------- It would be useful if heap profile data could be reported in the eventlog (either by assigning samples with IDs and recording the sample in the eventlog, or putting the entire profile information in the eventlog). This would make it easier to correlate heap profile data with other events reported by the RTS. It may be hard to stuff the entire sample in the eventlog because the sample is arbitrary size. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9051> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11415: Pandoc fails to build on 4 GB machine
by GHC 27 May '16

27 May '16

#11415: Pandoc fails to build on 4 GB machine -------------------------------------+------------------------------------- Reporter: pavolzetor | Owner: Type: bug | 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: -------------------------------------+------------------------------------- I made an attempt to install pandoc on laptop with 4 GB RAM and GHC was killed by OS after using all RAM and swap space (512 MB). Output from 'emerge pandoc' http://lpaste.net/148881 I can tolerate slow compile times, however this bug makes it impossible to build some packages which is worse. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11415> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11640: Panic because of "updateRole"
by GHC 27 May '16

27 May '16

#11640: Panic because of "updateRole" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Not the most recent GHC {{{#!hs {-# LANGUAGE RankNTypes, TypeInType #-} import Data.Kind data HEq :: forall k1. k1 -> forall k2. k2 -> Type where }}} gives {{{ % ghci -ignore-dot-ghci tx9F.hs GHCi, version 8.1.20160117: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( tx9F.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160117 for x86_64-unknown-linux): updateRole HEq k2_a115 [a114 :-> 0, a11e :-> 1, a11f :-> 2] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11640> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10604: Make Generic1 kind polymorphic
by GHC 27 May '16

27 May '16

#10604: Make Generic1 kind polymorphic -------------------------------------+------------------------------------- Reporter: | Owner: ekmett DerekElkins | Status: new Type: feature | Milestone: request | Version: 7.10.1 Priority: low | Operating System: Unknown/Multiple Component: Core | Type of failure: None/Unknown Libraries | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It looks to me that the Generic1 class (and the Rep1 associated type) can immediately be generalized to forall k. k -> *. If k was instantiated to anything other than *, you wouldn't be able to make an instance for Par1, but then I don't think it would ever come up so that would be exactly the right behavior. This allows, in particular, DataKinds to be used as a parameter to instances of Generic1. I don't know if this would affect deriving, but I wouldn't really expect it to. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10604> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9399: CPP does not process test case enum01.hs correctly
by GHC 25 May '16

25 May '16

#9399: CPP does not process test case enum01.hs correctly -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Keywords: cpp | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: enum01.hs Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The printTest cpp macro does not seem to be being applied in the test suite test enum01.hs (libraries/base) {{{ > ghci -cpp enum01.hs GHCi, version 7.8.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. [1 of 1] Compiling Main ( enum01.hs, interpreted ) enum01.hs:91:3: Not in scope: ‘printTest’ enum01.hs:92:3: Not in scope: ‘printTest’ : }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9399> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

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

25 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