July 2015 - ghc-tickets

[GHC] #8981: ghc-pkg complains about missing haddock interface files
by GHC 19 Feb '16

19 Feb '16

#8981: ghc-pkg complains about missing haddock interface files --------------------------+------------------------------------------------ Reporter: | Owner: thoughtpolice | Status: new Type: bug | Milestone: 7.8.2 Priority: normal | Version: 7.8.1 Component: | Operating System: MacOS X Compiler | Type of failure: Incorrect result at runtime Keywords: ghc- | Test Case: pkg | Blocking: Architecture: x86_64 | (amd64) | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ As Conal reported on the mailing list[1], `ghc-pkg check` on Mavericks allegedly returns: {{{ bash-3.2$ ghc-pkg check Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/uniplate-1.6.12/html/uniplate.haddock doesn't exist or isn't a file Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/polyparse-1.9/html/polyparse.haddock doesn't exist or isn't a file Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/ghc-syb-utils-0.2.1.2/html/ghc-syb-utils.haddock doesn't exist or isn't a file Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/constraints-0.3.5/html/constraints.haddock doesn't exist or isn't a file Warning: haddock-html: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/constraints-0.3.5/html doesn't exist or isn't a directory Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/newtype-0.2/html/newtype.haddock doesn't exist or isn't a file Warning: haddock-html: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/newtype-0.2/html doesn't exist or isn't a directory }}} It's not fatal, but makes the output much more annoying. I figured this would have been caught by validate or somesuch, but apparently not. Marking for 7.8.2. I'm looking into this soon. [1]http://www.haskell.org/pipermail/glasgow-haskell- users/2014-April/024846.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8981> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9611: Suggest the cause of "No instance" errors involving multiple versions of a package
by GHC 18 Feb '16

18 Feb '16

#9611: Suggest the cause of "No instance" errors involving multiple versions of a package -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | 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: -------------------------------------+------------------------------------- Suppose I have packages A-1.0, A-1.1, and B-1.0 built against A-1.0, and A (both versions) defines a type T which B defines to be an instance of some class C. If I load A-1.1 and B-1.0 into ghci and try to use the C T instance I will get a "No instance for C T" error, because T refers to A-1.1:T and B only defines an instance for A-1.0:T. However, if I don't realize this is what's going on, the error will be quite confusing as B appears to define an instance C T. Or, A could define the class C, rather than the type T, with the same result. This is quite common nowadays because there is a newer version of transformers (0.4.1.0) than the one which ships with GHC (0.3.0.0) and it's easy to end up installing mtl or lens against 0.3.0.0, and then some other package which pulls in 0.4.1.0. It would be nice to give a hint about what is going on, like {{{ No instance for (MonadIO X) arising from a use of ‘liftIO’ In the expression: ... ... Note: there is an instance transformers-0.3.0.0:MonadIO X }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9611> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9648: ghci fails to reload after deleting/creating an imported module
by GHC 17 Feb '16

17 Feb '16

#9648: ghci fails to reload after deleting/creating an imported module -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- If you start GHCi with a 2 module program, delete the child module, reload, you get an error (as expected). If you recreate the child module and reload, it reloads the dependent module but erroneously claims that parent can't find the child. Note that if you rename the child to something else, then rename it back, then the test works - so it seems the reappearance and the file stamp confuses ghci. Spotted while working on ghcid: https://github.com/ndmitchell/ghcid {{{ $ echo module Util where > Util.hs $ echo import Util; main = print 1 > Main.hs $ ghci Main.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 2] Compiling Util ( Util.hs, interpreted ) [2 of 2] Compiling Main ( Main.hs, interpreted ) Ok, modules loaded: Util, Main. *Main> :!del Util.hs *Main> :r Main.hs:1:8: Could not find module `Util' It is a member of the hidden package `ghc-7.8.3'. Use -v to see a list of the files searched for. Failed, modules loaded: Util, Main. *Main> :!echo module Util where > Util.hs *Main> :r [1 of 2] Compiling Util ( Util.hs, interpreted ) [2 of 2] Compiling Main ( Main.hs, interpreted ) [Util changed] Main.hs:1:1: Failed to load interface for `Util' It is a member of the hidden package `ghc-7.8.3'. Use -v to see a list of the files searched for. Failed, modules loaded: Util. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9648> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9041: NCG generates slow loop code
by GHC 17 Feb '16

17 Feb '16

#9041: NCG generates slow loop code -------------------------+------------------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.6.3 Component: | Operating System: Unknown/Multiple Compiler (NCG) | Type of failure: Compile-time performance bug Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- In http://stackoverflow.com/a/23322255/263061 we compile the code {{{ main :: IO () main = do loop (maxBound :: Word32) $ \i -> do when (i `rem` 100000000 == 0) $ putStrLn "foo" }}} and compare the assembly generated by the NCG and `-fllvm`. The LLVM code is 10 times faster. While the LLVM code looks great, NCG one generated looks quite unfortunate and messy, with a lot of unnecessary `mov`ing around. I am by no means an expert in this, but some of it looks like low hanging potential improvements. This is the '''LLVM code''': {{{ Main_zdwa_info: .LBB1_1: movl $4294967295, %esi /* load the loop bound */ movabsq $-6067343680855748867, %rdi /* load a magic number for the modulus */ jmp .LBB1_2 .LBB1_4: incl %ecx /* loop core start */ .LBB1_2: cmpq %rsi, %rcx je .LBB1_6 /* check loop bound */ /* do the modulus with two multiplications, a shift and a magic number */ /* note : gcc does the same reduction */ movq %rcx, %rax mulq %rdi shrq $26, %rdx imulq $100000000, %rdx, %rax cmpq %rax, %rcx jne .LBB1_4 /* loop core end */ /* Code omitted: print, then return to loop beginning */ .LBB1_6: }}} So the core of the loop is a nice and short: {{{ incl cmpq je movq [division replaced by magic multiplication] mulq shrq imulq cmpq jne }}} Now what '''NCG''' produces: {{{ Main_zdwa_info: /* loop core start */ .Lc3JD: leaq -16(%rbp),%rax /* stack check */ cmpq %r15,%rax jb .Lc3JO /* jump not taken in the normal case */ .Lc3JP: movl $4294967295,%eax /* issue: loading the bound on every iteration */ cmpq %rax,%r14 jne .Lc3JB .Lc3JC: /* Return from main. Code omitted */ .Lc3JB: /* test the index for modulus */ movl $100000000,%eax /* issue: unnecessary moves */ movq %rax,%rbx /* and loading the modulo arg on every iteration */ movq %r14,%rax xorq %rdx,%rdx /* shorter alternative to mov $0,%rdx */ divq %rbx /* issue: doing the division (llvm and gcc avoid this) */ testq %rdx,%rdx jne .Lc3JU /* This jump is usually taken. */ .Lc3JV: /* do the printing. Code omitted. Not relevant */ .Lc3JN: /* increment index and (I guess) restore registers messed up by the printing */ movq 8(%rbp),%rax /* This code is not very relevant because we don't almost never */ incq %rax movl %eax,%r14d addq $16,%rbp jmp Main_zdwa_info .Lc3JU: leaq 1(%r14),%rax /*issue: why not just increment r14? */ movl %eax,%r14d jmp Main_zdwa_info }}} So the core of this loop is {{{ movl [stack check] cmpq jne movl movq movq xorq divq testq jne leaq movl jmp }}} Some issues here: * the stack check is inside the loop * the loop limit is loaded every time inside the loop * the modulo arg is loaded every time inside the loop * we are shuffling around registers * no strength reduction (div is not replaced by cheaper magic number imul) * weird increment using leaq It would be great if somebody with codegen insight could comment on whether these are easy targets for improvement! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9041> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9637: Type level programming needs an error function
by GHC 17 Feb '16

17 Feb '16

#9637: Type level programming needs an error function -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | 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 doing type level programming you often need a way to report errors. I suggest a closed type family called Error with special semantics. It is kinded like this Error :: Symbol -> k1 -> k2 If this function has to be reduced during constraint solving it will simply generate a type error with the given string and printing the type as extra information (this kind can be generalized a lot if we want to). I've found that having this function gives more accurate and earlier error messages. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9637> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #8927: Multiple case match at once
by GHC 16 Feb '16

16 Feb '16

#8927: Multiple case match at once -------------------------------------------+------------------------------- Reporter: vxanica | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.6.3 Keywords: case, multiple | 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: -------------------------------------------+------------------------------- In F# we can do {{{ #!div style="font-size: 120%" {{{#!haskell match x with | 1 | 2 | 3 -> "123" | 4 | 5 | 6 -> "456" }}} }}} It will be nice if we have an extension which allows us to do {{{ #!div style="font-size: 120%" {{{#!haskell case x of 1 | 2 | 3 -> "123" 4 | 5 | 6 -> "456" }}} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8927> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10478: Shorter import syntax
by GHC 15 Feb '16

15 Feb '16

#10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It would be helpful to support a short syntax for importing unqualified identifiers while establishing a short qualified name. An example of the proposed syntax is, {{{#!hs import Data.Map (Map) as M }}} The desired semantics are that `Map` be imported unqualified, and `M` be defined as an alias for `Data.Map`. This replaces the existing convention of writing, {{{#!hs import Data.Map (Map) import qualified Data.Map as M }}} The proposed syntax is currently an error, I think, so adding support for it should not break anything. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10478> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #8278: Improve error message when the same type is imported from two different library versions
by GHC 14 Feb '16

14 Feb '16

#8278: Improve error message when the same type is imported from two different library versions ------------------------------------+------------------------------------- Reporter: Yuras | 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: | ------------------------------------+------------------------------------- When a package indirectly depends on different versions of the same library, ghc reports cryptic error: {{{ Couldn't match expected type `ByteString' with actual type `bytestring-0.9.2.1:Data.ByteString.Internal.ByteString' }}} Error contains fully qualified type with package name and version only when the type is imported from different versions on the library, so looks like ghc knows what is wrong. Is it possible to add something like the next: {{{ Note: ByteString is imported from different package versions: bytestring-0.9.2.1 and bytestring-0.10.0.1 }}} It is inspired by a number of StackOverflow questions (e.g. http://stackoverflow.com/questions/12576817/couldnt-match-expected-type- with-actual-type-error-when-using-codec-bmp/12577025#12577025, http://stackoverflow.com/questions/18767086/bytestring-to-lazy-text-and- vice-versa/18769431?noredirect=1#comment27676563_18769431) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8278> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10576: REPL returns list of all imported names when operator completion requested
by GHC 14 Feb '16

14 Feb '16

#10576: REPL returns list of all imported names when operator completion requested -------------------------------------+------------------------------------- Reporter: Geraldus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple completions complete command | Type of failure: Incorrect result operator | at runtime Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When querying completions for operators GHCi returns a list containing all imported names rather than suitable completions. For example, if you simply start GHCi and run `:complete repl ">>"` command it will give you all names from base and Prelude. Then if you import something else, for example `:m +Data.Text`, the result of query will contain names from Data.Text also. In case of projects (`cabal repl`) things are worst, because returned list contains all names imported project-wise and it could be really huge. GHCi behaves similarly with following queries: :complete repl "(>>" :complete repl "Prelude.>>" :complete repl "Prelude.(>>" I only tested this on OS X 10.9, GHC 7.8.4 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10576> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9920: Segfault in arm binary
by GHC 13 Feb '16

13 Feb '16

#9920: Segfault in arm binary ----------------------------+------------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------+------------------------------------------- Using ghc HEAD (6713f0d9a) I compile a very simple program which segfaults immediately. Stepping through it using GDB I find its crashing on the instruction {{{ 0x3f5a98 <stg_init_finish$def+12> ldr r5, [r5] }}} and that just before this instruction the value of `r5` is zero. That means its trying to load into `r5` the value at the address in `r5`. Obviously that's going to segfault. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9920> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22