June 2016 - ghc-tickets

Re: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space
by GHC 09 Jun '16

09 Jun '16

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2304 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Per SPJ's request, I've reposted some sleuthing I did in [https://phabricator.haskell.org/D2304#67314 the comments] of Phab:D2304. I decided to my changes on the 300-constructor sum type mentioned at the top of this ticket. I manually implemented a `Generic` instance for this datatype three times, and put each one in its own file: * [https://gist.github.com/RyanGlScott/e1ef13b59440200e696f5ca0c23dfb8c #file-gen_v1-hs Gen_v1.hs], which contains a `Generic` instance as GHC derives it currently (without the changes in Phab:D2304) * [https://gist.github.com/RyanGlScott/e1ef13b59440200e696f5ca0c23dfb8c #file-gen_v2-hs Gen_v2.hs], which is like `Gen_v1.hs` except that it factors out the topmost `M1` in `from`/`to` (i.e., with the changes in Phab:D2304) * [https://gist.github.com/RyanGlScott/e1ef13b59440200e696f5ca0c23dfb8c #file-gen_v3-hs Gen_v3.hs], which is like `Gen_v1.hs` except that it both (1) factors out the topmost `M1` in `from`/`to` and (2) factors out common occurrences of `L1`/`R1` in `to` I compiled each file with `ghc -O2 -v3 +RTS -s` and dumped the results to logs. Here are the highlights: * [https://gist.githubusercontent.com/RyanGlScott/e1ef13b59440200e696f5ca0c23d… Gen_v1.txt] * `{terms: 16,282, types: 2,563,921, coercions: 639,012}` * `7,781,716,432 bytes allocated in the heap` * `Total time 8.708s ( 8.719s elapsed)` * [https://gist.githubusercontent.com/RyanGlScott/e1ef13b59440200e696f5ca0c23d… Gen_v2.txt] * `{terms: 16,288, types: 2,924,492, coercions: 9,950}` * `4,479,400,544 bytes allocated in the heap` * `Total time 5.580s ( 5.590s elapsed)` * [https://gist.githubusercontent.com/RyanGlScott/e1ef13b59440200e696f5ca0c23d… Gen_v3.txt] * `{terms: 16,288, types: 2,924,492, coercions: 9,950}` * `4,016,934,848 bytes allocated in the heap` * `Total time 4.990s ( 5.006s elapsed)` There is a huge difference between `v1` and `v2`, as suspected. There is a difference between `v2` and `v3` in that it allocated fewer bytes on the heap, but interestingly, `v3` has the exact same number of types and coercions, so I'm not sure where the improvement is coming from. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8510: Clear up what extensions are needed at a Template Haskell splice site
by GHC 09 Jun '16

09 Jun '16

#8510: Clear up what extensions are needed at a Template Haskell splice site ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Suppose you write {{{ module M where data T = ... $(cleverThFunction ''T) }}} where `cleverThFunction` is some Template Haskell code in a library somewhere. Question: * '''If `cleverThFunction` generates code that uses `GADTs`, or `ConstraintKinds`, or `TypeFamilies` or whatnot, do those language extension flags have to be in force in module M, or only at the definition of `cleverThFunction`?''' Currently the situation is anarchic; see below. It should be made tidy. My personal preference is to say that the extensions must be in force in the definition of `cleverThFunction`, but '''not''' at the splice site. Reason: the client doesn't know or care how `cleverThFunction` works. This decision would be compatible with the handling of overlapping instances. Gergely writes: There are a lot of extensions that simply can't be used with TH: {{{ - n+k, - RecursiveDo, - TransformListComp, - Arrows, - ImplicitParams, - TupleSections, - Monadcomprehensions. }}} The rest can be grouped into two parts. The following extensions still work when spliced in without the corresponding language pragma: {{{ - UnicodeSyntax, - LambdaCase, - NamedFieldPuns, - RecordWildCards, - DataTypeContexts (and you get rid of the deprecation warning generation this way :)), - ConstraintKind, - MagicHash (note that UnboxedTuples is in the other part), - TraditionalRecordSyntax, - MultiWayIf, - GADTs (extra nice example at the end of this message). }}} The following needs the pragma at the place of splicing: {{{ - PostfixOperators, - ScopedTypeVariables, - Rank2, RankN, - deriving typeable and data, - UnboxedTuples, - ViewPatterns, - ParallelListComp, - ExistentialQuantification, - EmptyDataDecls, - TypeFamilies, - MultiParamTypeClasses, - FunctionalDependencies. }}} I don't see any trivial distinction, like based on Reader vs Typechecker, or anything like that. In particular * Note `ViewPatterns` vs `LambdaCase`. * Note `GADTs` vs `Rank2`. A very interesting example is `ExplicitForAll`. The AST for polymorphic functions always have explicit foralls in TH.Syntax; so there is no way to require the user at the point of splicing to enable the language extension. GADTs are cool too: {{{ {-# LANGUAGE TemplateHaskell #-} -- No need for GADTs at all! -- {-# LANGUAGE GADTs #-} $([d| data Foo where Foo1 :: Int -> Foo Foo2 :: String -> Foo f1 :: Foo f1 = Foo1 5 f :: Foo -> Either Int String f (Foo1 n) = Left n f (Foo2 s) = Right s |]) main = print (f f1) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8510> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10569: Treat an out-of-scope variable like a typed hole
by GHC 08 Jun '16

08 Jun '16

#10569: Treat an out-of-scope variable like a typed hole -------------------------------------+------------------------------------- Reporter: simonpj | 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: | -------------------------------------+------------------------------------- If we have {{{ f x = x + y }}} GHC currently reports `Not in scope: y`, and halts. It would be cool to treat `y` as a typed hole, so that * The out-of-scope message would give its type * Using `-fdefer-type-errors` we could defer the error to runtime. This was suggested in #5910 [https://ghc.haskell.org/trac/ghc/ticket/5910#comment:19 comment 19], and [http://haskell.1045720.n5.nabble.com/fdefer-more-errors-td5809991.html this Haskell Cafe thread] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10569> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12167: <<loop>> when zip + unzipping a shadowed Vector type variable
by GHC 08 Jun '16

08 Jun '16

#12167: <<loop>> when zip + unzipping a shadowed Vector type variable -------------------------------------+------------------------------------- Reporter: markog | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs module Main where import Data.Vector.Unboxed (Vector) import qualified Data.Vector.Unboxed as V (|>) :: a -> (a -> b) -> b x |> f = f x main = do s <- do x <- return $ V.fromList [1,2,3,4] :: IO (Vector Int) d <- return $ V.fromList [1,2,3,4] :: IO (Vector Int) let xd :: (Vector Int, Vector Int) xd = V.zip x d |> V.unzip (x,d) = xd -- here is where the error happens -- returning xd works -- removing the shadowing also works in return x print s }}} I do not see how the above code warrants a <<loop>> error as there is really no recursion in it. The linter always complains when I shadow variables, but I often use the above style in F# to reduce the namespace bloat. Shadowing is not a problem when the variables have different types. Is the above really a compiler error? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12167> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12166: Pattern synonym existential variable confusion
by GHC 08 Jun '16

08 Jun '16

#12166: Pattern synonym existential variable confusion -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Ponder this: {{{ magic :: Int -> a magic = undefined pattern Silly :: a -> Int pattern Silly a <- (magic -> a) }}} According to the rules for implicit quantification in pattern signatures, the `a` in `Silly`'s type is labeled as existential. That's sensible enough. But what surprised me is that the code is accepted, even though the pattern `(magic -> a)` doesn't bring any existentials into scope. Apparently, GHC is clever enough not to produce a core-lint error, and it actually treats the variable as existential, as witnessed by {{{ foo (Silly x) = x }}} which fails to compile because of skolem-escape. If you change the pattern signature to {{{ pattern Silly :: forall a. a -> Int }}} that changes `a` to be universal, and then `foo` is accepted. I think the original program, with `a` inferred to be existential, should be rejected. (The inference around universal/existential is not at issue. With a signature `pattern Silly :: () => forall a. a -> Int`, the program is still accepted when it shouldn't be.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12166> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7105: Better names for derived SCCs of instances
by GHC 08 Jun '16

08 Jun '16

#7105: Better names for derived SCCs of instances -------------------------------------+------------------------------------- Reporter: ksf | Owner: simonmar Type: feature request | Status: merge Priority: normal | Milestone: Component: Profiling | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11543 | Differential Rev(s): Phab:D2282 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => merge -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7105#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7105: Better names for derived SCCs of instances
by GHC 08 Jun '16

08 Jun '16

#7105: Better names for derived SCCs of instances -------------------------------------+------------------------------------- Reporter: ksf | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11543 | Differential Rev(s): Phab:D2282 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan <omeragacan@…>): In [changeset:"d7933cbc28f4f094eba3d128bc147920f68c965b/ghc" d7933cbc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d7933cbc28f4f094eba3d128bc147920f68c965b" Show sources of cost centers in .prof This fixes the problem with duplicate cost-centre names that was reported a couple of times before. When a module implements a typeclass multiple times for different types, methods of different implementations get same cost-centre names and are reported like this: COST CENTRE MODULE %time %alloc CAF GHC.IO.Handle.FD 0.0 32.8 CAF GHC.Read 0.0 1.0 CAF GHC.IO.Encoding 0.0 1.8 showsPrec Main 0.0 1.2 readPrec Main 0.0 19.4 readPrec Main 0.0 20.5 main Main 0.0 20.2 individual inherited COST CENTRE MODULE no. entries %time %alloc %time %alloc MAIN MAIN 53 0 0.0 0.2 0.0 100.0 CAF Main 105 0 0.0 0.3 0.0 62.5 readPrec Main 109 1 0.0 0.6 0.0 0.6 readPrec Main 107 1 0.0 0.6 0.0 0.6 main Main 106 1 0.0 20.2 0.0 61.0 == Main 114 1 0.0 0.0 0.0 0.0 == Main 113 1 0.0 0.0 0.0 0.0 showsPrec Main 112 2 0.0 1.2 0.0 1.2 showsPrec Main 111 2 0.0 0.9 0.0 0.9 readPrec Main 110 0 0.0 18.8 0.0 18.8 readPrec Main 108 0 0.0 19.9 0.0 19.9 It's not possible to tell from the report which `==` took how long. This patch adds one more column at the cost of making outputs wider. The report now looks like this: COST CENTRE MODULE SRC %time %alloc CAF GHC.IO.Handle.FD <entire-module> 0.0 32.9 CAF GHC.IO.Encoding <entire-module> 0.0 1.8 CAF GHC.Read <entire-module> 0.0 1.0 showsPrec Main Main_1.hs:7:19-22 0.0 1.2 readPrec Main Main_1.hs:7:13-16 0.0 19.5 readPrec Main Main_1.hs:4:13-16 0.0 20.5 main Main Main_1.hs:(10,1)-(20,20) 0.0 20.2 individual inherited COST CENTRE MODULE SRC no. entries %time %alloc %time %alloc MAIN MAIN <built-in> 53 0 0.0 0.2 0.0 100.0 CAF Main <entire-module> 105 0 0.0 0.3 0.0 62.5 readPrec Main Main_1.hs:7:13-16 109 1 0.0 0.6 0.0 0.6 readPrec Main Main_1.hs:4:13-16 107 1 0.0 0.6 0.0 0.6 main Main Main_1.hs:(10,1)-(20,20) 106 1 0.0 20.2 0.0 61.0 == Main Main_1.hs:7:25-26 114 1 0.0 0.0 0.0 0.0 == Main Main_1.hs:4:25-26 113 1 0.0 0.0 0.0 0.0 showsPrec Main Main_1.hs:7:19-22 112 2 0.0 1.2 0.0 1.2 showsPrec Main Main_1.hs:4:19-22 111 2 0.0 0.9 0.0 0.9 readPrec Main Main_1.hs:7:13-16 110 0 0.0 18.8 0.0 18.8 readPrec Main Main_1.hs:4:13-16 108 0 0.0 19.9 0.0 19.9 CAF Text.Read.Lex <entire-module> 102 0 0.0 0.5 0.0 0.5 To fix failing test cases because of different orderings of cost centres (e.g. optimized and non-optimized build printing in different order), with this patch we also start sorting cost centres before printing. The order depends on 1) entries (more entered cost centres come first) 2) names (using strcmp() on cost centre names). Reviewers: simonmar, austin, erikd, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2282 GHC Trac Issues: #11543, #8473, #7105 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7105#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11543: Profiling information ambiguous
by GHC 08 Jun '16

08 Jun '16

#11543: Profiling information ambiguous -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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: -------------------------------------+------------------------------------- If a module M contains two instances of class C with method m and you ask for top level functions to be profiled then you get two profile entries for method m, and you cannot tell which is which. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11543> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9034: GHCi panics when given C++ object file on GNU/Linux
by GHC 08 Jun '16

08 Jun '16

#9034: GHCi panics when given C++ object file on GNU/Linux ------------------------------------------+------------------------------- Reporter: jun0 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Keywords: panic, dynamic linking | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------------+------------------------------- When given a C++ object file, GHCi panics saying that it can't find standard C++ symbols the object file relies on. If foo.cc contains {{{#!C++ #include <iostream> extern "C" void foo () { std::cout << "bar"; } }}} and is compiled with {{{ g++ -fPIC -c -o foo.o foo.cc }}} then {{{ ghci foo.o -lstdc++ }}} fails with {{{ GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static) foo.o ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc14109_0/ghc14109_1.so: undefined symbol: _ZSt4cout Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It makes no difference to add -L<C++ library paths> which was, IIRC, necessary in older versions of GHC. This applies to only GHCi with C++ -- GHC can link C++ object files just fine, while GHCi has no trouble loading C object files. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9034> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 08 Jun '16

08 Jun '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka <niteria@…>): In [changeset:"d4b548efea15943026dd0d4929b6f0f999b4d718/ghc" d4b548e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d4b548efea15943026dd0d4929b6f0f999b4d718" Add some determinism tests These are the tests that I accumulated fixing real issues. Each test is a separate thing that was broken and they are relatively small. GHC Trac: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:201> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0