January 2015 - ghc-tickets

[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] #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] #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

[GHC] #9022: TH pretty printer and GHC parser semicolon placement mismatch
by GHC 12 Feb '16

12 Feb '16

#9022: TH pretty printer and GHC parser semicolon placement mismatch ----------------------------+---------------------------------------------- Reporter: roldugin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- In GHC 7.8 TemplateHaskell pretty printer started inserting explicit braces and semicolons. It puts semicolons at the end of the line as opposed to the beginning of the next line. This causes GHC to fail parsing if we try to compile the pretty printed code. {{{ $ cat Foo.hs module Main where import Language.Haskell.TH main = putStrLn $ pprint foo foo :: Dec foo = barD where barD = FunD ( mkName "bar" ) [ Clause manyArgs (NormalB barBody) [] ] barBody = DoE [letxStmt, retxStmt] letxStmt = LetS [ ValD (VarP xName) (NormalB $ LitE $ IntegerL 5) [] ] retxStmt = NoBindS $ AppE returnVarE xVarE xName = mkName "x" returnVarE = VarE $ mkName "return" xVarE = VarE xName manyArgs = map argP [0..9] argP n = VarP $ mkName $ "arg" ++ show n $ ghc-7.8.2 Foo.hs [1 of 1] Compiling Main ( Foo.hs, Foo.o ) Linking Foo ... $ ./Foo | tee Bar.hs bar arg0 arg1 arg2 arg3 arg4 arg5 arg6 arg7 arg8 arg9 = do {let x = 5; return x} $ ghc Bar.hs [1 of 1] Compiling Main ( Bar.hs, Bar.o ) Bar.hs:2:61: parse error on input `return' }}} I don't know if this is a problem with TH pretty printer or if GHC is supposed to parse semicolons wherever they are.. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9022> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #9386: GHCi cannot load .so in same ./
by GHC 11 Feb '16

11 Feb '16

#9386: GHCi cannot load .so in same ./ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHCi crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In my directory ./ I have an empty file Foo.hs and a shared object file mylib.so. From that directory in the shell, $ ghci Foo *.so 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 (dynamic) mylib.so ... failed. <command line>: user specified .o/.so/.DLL could not be loaded (mylib.so: cannot open shared object file: No such file or directory) Whilst trying to load: (dynamic) mylib.so Additional directories searched: (none) It's interesting that GHCi searches ./ and identifies the correct object file, but then fails to load it. I have also tried the path ./*.so for the GHCi option. However, if I move mylib.so to a directory ./Temp, $ ghci Foo Temp/*.so loads without issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9386> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10022: Clean up GHC.RTS.Flags
by GHC 09 Feb '16

09 Feb '16

#10022: Clean up GHC.RTS.Flags -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice | Status: new Type: bug | Milestone: 7.12.1 Priority: normal | Version: 7.10.1-rc1 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: #9970 Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- There's some cleanup to do for `GHC.RTS.Flags`, based on the comments in https://ghc.haskell.org/trac/ghc/ticket/5364#comment:11 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10022> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8136: arr020 test fails randomly with ghci way
by GHC 07 Feb '16

07 Feb '16

#8136: arr020 test fails randomly with ghci way -----------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------+---------------------------------- I noticed that when I run arr020 (`make TEST=arr020`) it randomly segfaults when running `ghci` way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8136> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8265: getTokenStream fails for source using cpp
by GHC 07 Feb '16

07 Feb '16

#8265: getTokenStream fails for source using cpp -----------------------------------+--------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- Calling getTokenStream (or getRichTokenStream) on a module that has CPP directives fails as the lexer is given un-preprocessed source -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8265> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8842: Make sure msys2 builds non emulating binaries
by GHC 06 Feb '16

06 Feb '16

#8842: Make sure msys2 builds non emulating binaries ------------------------------------+--------------------------------- Reporter: schyler | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- I came across this in my own project. MSys2 doesn't enter #ifdef blocks which test for _WIN32. Instead, it pretends to be Linux and has a set of headers which emulate things like mmap. These emulation functions are really really slow -- in my personal tests about 10x slower than calling the WINAPI -- so this ticket is just a reminder (it may already be done) for someone to check that MSys2 builds things non-emulated in GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8842> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9686: Link option detection does not work for incremental builds on Windows
by GHC 06 Feb '16

06 Feb '16

#9686: Link option detection does not work for incremental builds on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: gintas Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- ghc on Linux embeds link options into the resulting binary in order to be able to tell when a binary needs to be recompiled because different link options have been passed in to ghc. This functionality is not present on Windows, forcing users to pass in -fforce-recomp. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9686> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2