October 2018 - ghc-tickets

[GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02`
by GHC 24 Jan '19

24 Jan '19

#13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- See the attached file. The compilation time grows exponentially with additional fields in `HuteStruct`. Tried with GHC-8.0.1 and quite recent HEAD (8.2) adding a field doubles the compilation time with `-O2`. - 9: 17s - 10: 34s - 11: 83s on my machine. With `-01` around 3sec, independently of the struct size. The original issue: https://github.com/yesodweb/yesod/issues/1348 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13253> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 45

[GHC] #12920: Overzealous unused-top-binds
by GHC 23 Jan '19

23 Jan '19

#12920: Overzealous unused-top-binds -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following example produces three warnings: {{{ module Foo () where type A = Int type B = A foo :: IO () foo = print (bar 3 :: B) bar :: a -> a bar = id }}} `ghci Foo -Wall` produces {{{ GHCi, version 8.0.1.20161117: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Foo.hs:5:1: warning: [-Wunused-top-binds] Defined but not used: type constructor or class ‘B’ Foo.hs:8:1: warning: [-Wunused-top-binds] Defined but not used: ‘foo’ Foo.hs:11:1: warning: [-Wunused-top-binds] Defined but not used: ‘bar’ Ok, modules loaded: Foo. }}} The three errors reported are inconsistent because GHC reports that `B` is unused, but somehow feels that `A` *is* used. It seems to me that two possibilities could work: 1. GHC reports 1 error: GHC should only report that `foo` is unused, since `A` is used in `B`, `B` is used in `foo`, and `bar` is used in `foo`. This seems like the best approach to me. 2. GHC reports 4 errors: One might choose to apply the definition of "unused" transitively so that, since `foo` is unused, everything used in `foo` is considered unused (unless "used" elsewhere). In this case, `A` should also be reported as unused, but it currently isn't. This definition would be exceedingly useful for removing dead code, but it also produces very noisy output when there is a lot of dead code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12920> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15470: Record projections with ambiguous types
by GHC 23 Jan '19

23 Jan '19

#15470: Record projections with ambiguous types -------------------------------------+------------------------------------- Reporter: sweirich | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- The following code fails {{{ {-# LANGUAGE DataKinds, KindSignatures, PolyKinds, TypeFamilies, RankNTypes, AllowAmbiguousTypes #-} module TypeLambda where data Fun a b type family App (f :: Fun t k) (x :: t) :: k data MONAD m = MONAD { return :: forall a. a -> App m a , (>>=) :: forall a b. App m a -> (a -> App m b) -> App m b } }}} with the error message {{{ TypeLambda.hs:12:5: error: • Couldn't match type ‘App m b0’ with ‘App m b’ Expected type: App m a -> (a -> App m b) -> App m b Actual type: App m a -> (a -> App m b0) -> App m b0 NB: ‘App’ is a non-injective type family The type variable ‘b0’ is ambiguous • In the expression: (>>=) In an equation for ‘TypeLambda.>>=’: (TypeLambda.>>=) MONAD {>>= = (>>=)} = (>>=) • Relevant bindings include (>>=) :: forall a b. App m a -> (a -> App m b) -> App m b (bound at TypeLambda.hs:12:5) | 12 | , (>>=) :: forall a b. App m a -> (a -> App m b) -> App m b | ^^^^^ Failed, no modules loaded. }}} However, with ScopedTypeVariables and TypeApplications, it is possible to define the projections: {{{ data MONAD2 m = MONAD2 (forall a. a -> App m a) (forall a b. App m a -> (a -> App m b) -> App m b) bind :: forall b a m. MONAD2 m -> App m a -> (a -> App m b) -> App m b bind (MONAD2 _ b) = b @a @b }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15470> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15646: ghci takes super long time to find the type of large fractional number
by GHC 23 Jan '19

23 Jan '19

#15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Keywords: type | 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: -------------------------------------+------------------------------------- {{{ :t 1e123456789 }}} takes more than 3 seconds to get the type info. {{{ :t 1e1234111111111111111111111 }}} shows a warning/error, {{{ GNU MP: Cannot allocate memory (size=93978265) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 86

[GHC] #15733: Several links in GHC.Exts.Heap documentation are broken
by GHC 22 Jan '19

22 Jan '19

#15733: Several links in GHC.Exts.Heap documentation are broken -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- There are some broken links in the GHC.Exts.Heap documentation. https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc- heap-8.6.1/GHC-Exts-Heap.html For example, in `GenClosure`, the first link is wrong and redirects. http://hackage.haskell.org/trac/ghc/browser/includes/rts/storage/Closures.h Similarly in the definition of `StgInfoTable`. Those are the two I found. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15733> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15662: Line pragmas appear to be slightly broken with Clang's CPP
by GHC 22 Jan '19

22 Jan '19

#15662: Line pragmas appear to be slightly broken with Clang's CPP -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Two tests fail on OS X due to CPP irregularities, {{{ 7 --- /var/folders/3y/qjvrbynj45j_z4jt_l1k1qg00000gv/T/ghctest- jb4vg3rr/test spaces/parser/should_fail/readFail032.run/readFail032.stderr.normalised 2018-09-18 09:07:49.000000000 +0300 8 +++ /var/folders/3y/qjvrbynj45j_z4jt_l1k1qg00000gv/T/ghctest- jb4vg3rr/test spaces/parser/should_fail/readFail032.run/readFail032.comp.stderr.normalised 2018-09-18 09:07:49.000000000 +0300 9 @@ -1,5 +1,5 @@ 10 11 -readFail032.hs:25:38: 12 +readFail032.hs:26:38: 13 Couldn't match type ‘Char’ with ‘[Char]’ 14 Expected type: [[Char]] 15 Actual type: [Char] 16 --- /var/folders/3y/qjvrbynj45j_z4jt_l1k1qg00000gv/T/ghctest- jb4vg3rr/test spaces/parser/should_fail/readFail048.run/readFail048.stderr.normalised 2018-09-18 09:07:50.000000000 +0300 17 +++ /var/folders/3y/qjvrbynj45j_z4jt_l1k1qg00000gv/T/ghctest- jb4vg3rr/test spaces/parser/should_fail/readFail048.run/readFail048.comp.stderr.normalised 2018-09-18 09:07:50.000000000 +0300 18 @@ -1,5 +1,5 @@ 19 20 -readFail048.hs:25:38: 21 +readFail048.hs:26:38: 22 Couldn't match type ‘Char’ with ‘[Char]’ 23 Expected type: [[Char]] 24 Actual type: [Char] }}} This appears to be a CPP bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15662> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13586: ghc --make seems to leak memory
by GHC 22 Jan '19

22 Jan '19

#13586: ghc --make seems to leak memory -------------------------------------+------------------------------------- Reporter: | Owner: (none) MikolajKonarski | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #13379 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (This is probably not reproducible with a small example.) When I build this project with `cabal build` https://github.com/LambdaHack/LambdaHack/commit/138123ab13edd4db6c8143720af… the peek memory, as observed with `top`, is 10G*. When I instead interrupt the compilation with `^C` at the following point (compilation of this file take a couple of minutes, so it's easy to interrupt): {{{ [123 of 123] Compiling Game.LambdaHack.SampleImplementation.SampleMonadServer ( Game/LambdaHack/SampleImplementation/SampleMonadServer.hs, dist/build/Game/LambdaHack/SampleImplementation/SampleMonadServer.o ) }}} and then restart and continue to the end, peek memory usage in either of the two compilation parts is 5G*. So it seems `ghc --make` keeps some data that is either eventually not used or could as well be read on demand instead of kept in memory. Confirmed with 8.2.1-rc1 as well, but it's not trivial to compile due to restrictive upper bounds of many packages. *exact numerical values are made up -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13586> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #12953: Use computed gotos in the interpreter when the compiler supports it
by GHC 22 Jan '19

22 Jan '19

#12953: Use computed gotos in the interpreter when the compiler supports it -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: interpreter | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We can use computed gotos to speed up the interpreter on systems that support them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12953> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14475: Upload documentation dumps
by GHC 22 Jan '19

22 Jan '19

#14475: Upload documentation dumps -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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: -------------------------------------+------------------------------------- Having a nightly job that would update https://downloads.haskell.org/~ghc/master/users-guide/ would be lovely. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14475> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9251: ghc does not expose brancheless max/min operations as primops
by GHC 21 Jan '19

21 Jan '19

#9251: ghc does not expose brancheless max/min operations as primops ------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 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: #9246 | ------------------------------------+------------------------------------- It was pointed out in #9246 that GHC currently does not expose primops for Max and Min on various unlifted types such as Float# and Double# and Int# and Word#, but that on most modern CPU architectures there is instruction level support for these operations. (Eg, Float# and #Double min and max can be provided on any 64bit x86 system pretty easily ) This ticket is to track doing that task. I'll probably do it one of the next two weekends to get back in the GHC hacking groove, or maybe this should be used as a "getting started" ticket for a new contributor? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9251> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23