January 2015 - ghc-tickets

Re: [GHC] #1851: "make install-strip" should work
by GHC 26 Jan '15

26 Jan '15

#1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * version: 7.9 => 7.10.1-rc1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1851#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9948: Recommend class constraint instead of instance constraint
by GHC 26 Jan '15

26 Jan '15

#9948: Recommend class constraint instead of instance constraint -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider the following example: {{{#!hs {-# LANGUAGE FlexibleInstances, UndecidableInstances #-} module Foo where class Foo a where foo :: Int -> a instance (Num a) => Foo a where foo x = error "" f :: Int -> a f = foo }}} GHC says {{{ No instance for (Num a) arising from a use of ‘foo’ Possible fix: add (Num a) to the context of the type signature for f :: Int -> a In the expression: foo In an equation for ‘f’: f = foo }}} A better error, in my opinion, would be: {{{ No instance for (Foo a) arising from a use of ‘foo’ Possible fix: add (Foo a) to the context of the type signature for f :: Int -> a In the expression: foo In an equation for ‘f’: f = foo }}} That is, I think GHC should recommend the superclass constraint arising from the use of `foo` rather than trying to match an instance and then recommending constraints from the instance. Here are several reasons a superclass constraint is preferable: 1. If the matching instance has several constraints, GHC will recommend putting *all* of those constraints on the function instead of a single superclass constraint. This (naively) results in unnecessarily long constraints on functions that call methods. 2. If the constraints on the instance change, GHC will recommend the corresponding change on the function constraints. This means the instance constraints are not isolated, but instead propagate through the code. 3. The instance constraints might not make sense on the function itself. For example, `f` might not use any methods from the `Num` class, but GHC recommends the `Num` constraint anyway. Recommending the direct superclass constraint should be **less** work for GHC than the current implementation: instead of trying to find a matching instance, it simply stops when it finds that `foo` is a method. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9948> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #1851: "make install-strip" should work
by GHC 25 Jan '15

25 Jan '15

#1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gidyn): Still a problem in 7.10.1 RC1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1851#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1851: "make install-strip" should work
by GHC 25 Jan '15

25 Jan '15

#1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * version: 7.8.4-rc1 => 7.9 * milestone: => 7.10.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1851#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7788: Recursive type family causes <<loop>>
by GHC 24 Jan '15

24 Jan '15

#7788: Recursive type family causes <<loop>> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.6.2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by int-e): Replying to [comment:6 goldfire]: > But, with 7.10, the following doesn't: > > {{{ > type family F a where > F a = F a > > id2 :: F a -> F a > id2 x = x > }}} > > This is slightly disturbing because `id2` is merely a specialization of `id`. I think this is wrong: `id2` does not have a type at all, and therefore does not specialize `id`. The same is true for the original example. If one looks at the code generated by ghc-7.8.3, it tries to produce a witness for {{{F (Fix Id)}}} being a type, and `foo` checks that witness (which fails, producing the observed {{{<<loop>>}}}) before producing `undefined`: {{{ -- core, with some non-essential parts omitted cobox_rVz :: Main.F (Main.Fix Main.Id) ~ GHC.Prim.Any cobox_rVz = cobox_rVz foo :: Main.Proxy (Main.F (Main.Fix Main.Id)) -> () foo = case cobox_rVz of GHC.Types.Eq# _ -> undefined }}} That said it's unfortunate that GHC 7.10 loops rather than erroring out for these examples. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7788#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10015: Give the DLL loader awareness of rpaths
by GHC 23 Jan '15

23 Jan '15

#10015: Give the DLL loader awareness of rpaths -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: MacOS X Keywords: | Type of failure: None/Unknown Architecture: x86_64 | Blocked By: (amd64) | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This is nix-related. I'm trying to build with the nix version of libiconv instead of system libiconv, and to facilitate this I'm running package builds in a sandbox. If I try to compile a module using TemplateHaskell, say {{{#!hs module Main where main :: IO () main = putStrLn $([|"Hello, world!"|]) }}} I get this from ghc --make: [1 of 1] Compiling Main ( main.hs, main.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... <command line>: can't load .so/.DLL for: libiconv.dylib (dlopen(libiconv.dylib, 9): no suitable image found. Did find: /usr/lib/libiconv.dylib: stat() failed with errno=1) When of course I'd rather it just try to dlopen /nix/store /lsvxsyw9w17d2rix740akjxyxcacgi3k-libiconv-41/lib/libiconv.dylib, the one it was built with. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10015> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9867: PatternSynonyms + ScopedTypeVariables triggers an internal error
by GHC 23 Jan '15

23 Jan '15

#9867: PatternSynonyms + ScopedTypeVariables triggers an internal error -------------------------------------+------------------------------------- Reporter: antalsz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When trying to give a type signature with a free type variable to a pattern in a pattern synonym, GHC dies with an internal error. Given the file {{{#!hs {-# LANGUAGE PatternSynonyms, ScopedTypeVariables #-} pattern Nil = [] :: [a] }}} the resulting error is {{{ Example.hs:2:22: GHC internal error: ‘a’ is not in scope during type checking, but it passed the renamer … tcl_env of environment: [] In an expression type signature: [a] In the expression: [] :: [a] In an equation for ‘$WNil’: $WNil = [] :: [a] Compilation failed. }}} The fix is to add `RankNTypes` and an explicit `forall`: {{{#!hs {-# LANGUAGE PatternSynonyms, ScopedTypeVariables, RankNTypes #-} pattern Nil = [] :: forall a. [a] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9867> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9955: ghc-stage1 compiles with bootstrapping ghc package, not the built one
by GHC 23 Jan '15

23 Jan '15

#9955: ghc-stage1 compiles with bootstrapping ghc package, not the built one -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Build | Version: 7.11 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Steps to reproduce: Build GHC using 7.10 as the bootstrapping compiler. Now check which GHC package stage 1 Main.hi was linked against, e.g. using `--show-iface`: {{{ [ezyang@hs01 ghc-validate2]$ ../ghc-7.10/inplace/bin/ghc-stage2 --show- iface ghc/stage1/build/Main.hi ... package dependencies: array-0.5.0.1 base-4.8.0.0 binary-0.7.2.3 bin-package-db-0.0.0.0 bytestring-0.10.6.0 containers-0.5.6.2 deepseq-1.4.0.0 directory-1.2.1.1 filepath-1.3.1.0 ghc-7.10.0.20141223 ghc-prim-0.3.1.0 hoopl-3.10.0.2 hpc-0.6.0.2 integer-gmp-1.0.0.0 process-1.2.1.0 time-1.5.0.1 transformers-0.4.2.0 unix-2.7.1.0 }}} Bad news! I think I introduced bug when I made GHC a wired in package: consequently when we ask GHC to link against a specific version of the GHC package, this flag is ignored. I don't actually know what the right way to fix this is, but we'll have to figure something out here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9955> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9856: Test suite regressions due to integer-gmp2
by GHC 23 Jan '15

23 Jan '15

#9856: Test suite regressions due to integer-gmp2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | 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: | Test Case: prof-doc- | fib linker_unload | Blocking: | Differential Revisions: Phab:D82 -------------------------------------+------------------------------------- According to my performance builders, changeset:c774b28/ghc (Phab:D82) caused prof-doc-fib and linker_unload to fail on both performance builders (Ubuntu 13.10 and Ubuntu 14.04): {{{ Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: linker_unload: /home/nomeata/logs/ghc-tmp-REV/libraries/integer-gmp2/dist- install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a: unknown symbol `__gmpn_rshift' linker_unload: resolveObjs failed make[3]: *** [linker_unload] Error 1 *** unexpected failure for linker_unload(normal) }}} and {{{ Actual prof output differs from expected: --- ./profiling/should_run/prof-doc-fib.prof.sample 2014-12-01 15:30:19.000000000 +0100 +++ ./profiling/should_run/prof-doc-fib.prof 2014-12-01 15:56:08.000000000 +0100 @@ -1,9 +1,9 @@ - Thu Oct 27 09:29 2011 Time and Allocation Profiling Report (Final) + Mon Dec 1 15:56 2014 Time and Allocation Profiling Report (Final) - fib +RTS -p -RTS + prof-doc-fib +RTS -hc -p -RTS - total time = 0.76 secs (38 ticks @ 20 ms) - total alloc = 247,940,020 bytes (excludes profiling overheads) + total time = 0.14 secs (135 ticks @ 1000 us, 1 processor) + total alloc = 107,829,304 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc @@ -13,13 +13,16 @@ individual inherited COST CENTRE MODULE no. entries %time %alloc %time %alloc -MAIN MAIN 102 0 0.0 0.0 100.0 100.0 - CAF Main 203 0 0.0 0.0 100.0 100.0 - main Main 204 1 0.0 0.0 100.0 100.0 - main.g Main 207 1 0.0 0.0 0.0 0.1 - fib Main 208 1973 0.0 0.1 0.0 0.1 - main.f Main 205 1 0.0 0.0 100.0 99.9 - fib Main 206 2692537 100.0 99.9 100.0 99.9 - CAF GHC.Conc.Signal 201 0 0.0 0.0 0.0 0.0 - CAF GHC.IO.Encoding.Iconv 191 0 0.0 0.0 0.0 0.0 - CAF GHC.IO.Handle.FD 183 0 0.0 0.0 0.0 0.0 +MAIN MAIN 45 0 0.0 0.0 100.0 100.0 + main Main 91 0 0.0 0.0 0.0 0.0 + CAF Main 89 0 0.0 0.0 100.0 100.0 + main Main 90 1 0.0 0.0 100.0 100.0 + main.f Main 94 1 0.0 0.0 100.0 99.9 + fib Main 95 2692537 100.0 99.9 100.0 99.9 + main.g Main 92 1 0.0 0.0 0.0 0.1 + fib Main 93 1973 0.0 0.1 0.0 0.1 + CAF GHC.IO.Handle.Text 86 0 0.0 0.0 0.0 0.0 + CAF GHC.IO.Handle.FD 82 0 0.0 0.0 0.0 0.0 + CAF GHC.Conc.Signal 78 0 0.0 0.0 0.0 0.0 + CAF GHC.IO.Encoding 76 0 0.0 0.0 0.0 0.0 + CAF GHC.IO.Encoding.Iconv 75 0 0.0 0.0 0.0 0.0 *** unexpected failure for prof-doc-fib(profasm) }}} The former is also observed by SPJ. The latter actually looks less like a regression, and more an improvement – maybe Herbert simply did not run a profiled version when updating test results? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9856> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9949: zipWith too strict in second argument in GHC-7.10.0
by GHC 23 Jan '15

23 Jan '15

#9949: zipWith too strict in second argument in GHC-7.10.0 -------------------------------------+------------------------------------- Reporter: Lemming | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.1-rc1 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- correct: {{{ $ ghci-7.8.4 -Wall Prelude> zipWith (==) "" undefined [] }}} incorrect: {{{ $ ghci-7.10.0.20141227 -Wall Prelude> zipWith (==) "" undefined *** Exception: Prelude.undefined }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9949> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17