January 2015 - ghc-tickets

[GHC] #8780: abs for IEEE floating point is slightly wrong.
by GHC 08 Mar '15

08 Mar '15

#8780: abs for IEEE floating point is slightly wrong. ------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: low | 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: | ------------------------------------+------------------------------------- Evaluating abs(-0) gives the answer -0. This unexpected since it breaks invariants like 1/(abs x) >= 0. So abs(-0) should be 0. This is also the norm for other languages. Together with this change, signum should also be changed so signum(-0) is -0. This maintains the invariant abs x * signum x == x. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8780> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9707: (Try to) restructure `base` to allow more use of `AutoDeriveTypeable`
by GHC 07 Mar '15

07 Mar '15

#9707: (Try to) restructure `base` to allow more use of `AutoDeriveTypeable` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | 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: -------------------------------------+------------------------------------- comment:ticket:9111:16 explains that import-cycles containing `Data.Typeable.Internal` (which provides the `Typeable` class `AutoDeriveTypeable` needs to be loaded for being able to operate) inside `base` make it difficult to use `AutoDeriveTypeable`, as well as making it more difficult to de-cycle the `base` import-dependency graph (see also attachment:typeable_deps.pngtypeable_deps.png) This ticket is about trying to find a way to restructure `base` in order to allow to define the `Typeable` instances directly at the type's defining site (and thus allow the use of `AutoDeriveTypeable`) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9707> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9995: :info enhancements
by GHC 05 Mar '15

05 Mar '15

#9995: :info enhancements -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: GHCi | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- `:info` is a very useful ghci command, but there are several improvements that could be made: * It would be useful if `:i` showed not only which module a name is defined in, but which module(s) it was imported from in the current session. * A variant of `:i` that just prints a definition, rather than a definition and all instances, would be useful in many cases. E.g. `:i Show` prints the definition of `Show`, but then it prints so many instances that the definition is scrolled way off the screen. * `:i ->` is a parse error; it should behave like `:i (->)`, the way it works for other type-level operators. * hvr had some more suggestions: "finding out which package a module belongs to", "and what module an 'as'-alias is associated with". (Currently I think modules are out of `:info`'s scope, but perhaps it would be a useful addition.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9995> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9987: GHC refuses to compile a file that starts with a Byte Order Mark (BOM)
by GHC 05 Mar '15

05 Mar '15

#9987: GHC refuses to compile a file that starts with a Byte Order Mark (BOM) -------------------------------------+------------------------------------- Reporter: Henk-Jan | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Windows Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Trying to compile a file that starts with a Byte Order Mark (BOM) results in the message like: Camels.hs:1:1: lexical error at character '\65279' No compilation is done. Note that, if a file is saved as UTF-8, Notepad adds this BOM to the beginning of the file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9987> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8274: Core pretty-printer doesn't print # on unboxed literals
by GHC 03 Mar '15

03 Mar '15

#8274: Core pretty-printer doesn't print # on unboxed literals ------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I just noticed that Core pretty printer produces something like this (this is part of expected output for T3772 in testsuite): {{{ case GHC.Prim.<=# n# 0 of _ { __DEFAULT -> xs n#; 1 -> GHC.Tuple.() } }}} Both `0` (in scrutinee) and `1` (one of branch alternatives) are unboxed values, so they should be printed as `0#` and `1#` respectively. I haven't checked whether unboxed literals of other types (`Word`, `Double`, `Float`) are printed in that way, but I would guess that yes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8274> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10003: integer-gmp2 tries to be GMP 4.x compatible but uses functions from GMP 5.x
by GHC 03 Mar '15

03 Mar '15

#10003: integer-gmp2 tries to be GMP 4.x compatible but uses functions from GMP 5.x -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.11 (other) | Operating System: Solaris Keywords: | Type of failure: Building GHC Architecture: sparc | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Hello, recent HEAD is using integer-gmp2 wrapper around GMP library. This tries to be compatible with and use only functionality of GMP 4.x, but still it also uses some functions from GMP 5.x which makes this incompatible with GMP 4.x. The issue is for example shown on Solaris/SPARC platform where the OS provided library is GMP 4.3.2 and linking of stage2 binaries fails with: {{{ Undefined first referenced symbol in file __gmpn_andn_n /home/karel/src/ghc-sparc-reg_ncg-head-2015-01-17/libraries /integer-gmp2/dist- install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a(Type.o) __gmpn_and_n /home/karel/src/ghc-sparc-reg_ncg-head-2015-01-17/libraries /integer-gmp2/dist- install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a(Type.o) __gmpn_ior_n /home/karel/src/ghc-sparc-reg_ncg-head-2015-01-17/libraries /integer-gmp2/dist- install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a(Type.o) __gmpn_xor_n /home/karel/src/ghc-sparc-reg_ncg-head-2015-01-17/libraries /integer-gmp2/dist- install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a(Type.o) ld: fatal: symbol referencing errors. No output written to ghc/stage2/build/tmp/ghc-stage2 }}} the unresolve symbols are from GMP 5.x. GMP 4.x does not provide them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10003> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8342: System.Directory.getPermissions does not work well on Windows 7
by GHC 02 Mar '15

02 Mar '15

#8342: System.Directory.getPermissions does not work well on Windows 7 ---------------------------------------+--------------------------------- Reporter: freizl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/directory | Version: 7.4.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ---------------------------------------+--------------------------------- It works well for following code {{{ System.Directory.getPermissions "/path/to/somewhere" }}} However getting error with this: {{{ System.Directory.getPermissions "/path/to/somewhere/" *** Exception: getPermissions: does not exist (No such file or directory) }}} The only difference is the path name. It gets error when having extra trailing slash. It looks wired. Thanks your help. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8342> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9044: createDirectoryIfMissing does not fail on unwritable parent dir
by GHC 02 Mar '15

02 Mar '15

#9044: createDirectoryIfMissing does not fail on unwritable parent dir -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 libraries/directory | Operating System: MacOS X Keywords: | Type of failure: Incorrect result Architecture: Unknown/Multiple | at runtime Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- On OSX, using `createDirectoryIfMissing` to create a new directory inside a directory for which we do not have write permissions does not throw any exception. Of course it should throw an exception, as it does under Linux. {{{ $ mkdir unwritable $ chmod ugo-w unwritable $ ghci > System.Directory.createDirectoryIfMissing True "unwritable/tst" > }}} On OSX (10.9.2) this does not fail. Under Linux (albeit with 7.6.3) this does throw an exception as expected: {{{ *** Exception: unwritable/tst: createDirectory: permission denied (Permission denied) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9044> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9901: Error message: f is applied to two arguments, but its type has only two (sic)
by GHC 02 Mar '15

02 Mar '15

#9901: Error message: f is applied to two arguments, but its type has only two (sic) -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I occasionally get type errors where the error message refers to a function’s arity in a contradictory way: > The function ‘X’ is applied to two arguments, […] but its type has only two. Here’s a full error message of this kind: lenstest.hs:89:12: Couldn't match type ‘Either String Int’ with ‘Maybe b0’ Expected type: [Char] -> Either String Int Actual type: [Char] -> Maybe b0 The function ‘preview’ is applied to two arguments, but its type ‘Getting (Data.Monoid.First b0) (Either b0 c0) b0 -> [Char] -> Maybe b0’ has only two In the second argument of ‘($)’, namely ‘(preview _Left "abc" :: Either String Int)’ In a stmt of a 'do' block: print $ (preview _Left "abc" :: Either String Int) Failed, modules loaded: none. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9901> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9697: ./configure fails due to obselete usage of 'find -perm' in aclocal.m4
by GHC 02 Mar '15

02 Mar '15

#9697: ./configure fails due to obselete usage of 'find -perm' in aclocal.m4 -------------------------------------+------------------------------------- Reporter: nich | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.3 Keywords: aclocal.m4 find | Operating System: perm | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Building Difficulty: Easy (less than 1 | GHC failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- ./configure produces error message when building on current Fedora (20). According to find ver 4.5.11 the usage '-perm +XXX' has been deprecated since 2005 (use '-perm \XXX' instead). The message '/usr/bin/find: invalid mode '+111' ' is seen several times as a result. Whether this has any material impact I am not qualified to judge. I am actually trying to build HaLVM (from Galois) and first noticed the issue in their fork of GHC. However, this behaviour is also present in git HEAD (commit d7867810d5ffd08c77c30e928bb3dca21beae0b9). Making the obvious one line change in aclocal.m4 resolves the issue, and produces a clean build, for me at least. Patch attached -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9697> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6