February 2015 - ghc-tickets

[GHC] #9524: GHC uses wrong linker when cross compiling
by GHC 09 Mar '15

09 Mar '15

#9524: GHC uses wrong linker when cross compiling -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Building Blocked By: | GHC failed Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Greetings, I tried to compile a cross compiler for x86_64-w64-mingw32. Most of GHC compiles fine. However, after a while there's an error that ld can't find a reference to "GetModuleFileNameW". I tried compiling a dummy C program with that symbol and it compiles fine. My guess is that GHC is using the wrong linker during cross-compiling, whereas GCC uses the right one. But I may be totally wrong, so please don't rely on that judgement. The log of the make run is attached. Regards Sven -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9524> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10113: Re-export (<$>) from Prelude
by GHC 09 Mar '15

09 Mar '15

#10113: Re-export (<$>) from Prelude -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: highest | Version: 7.10.1-rc2 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: AMP | Blocked By: Architecture: | Related Tickets: #4834 Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: Phab:D680 | -------------------------------------+------------------------------------- See http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161 for details decision is still outstanding, but this needs to go into RC3 unless there's good reasons not to -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10113> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[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] #10118: No ambiguity check when `ConstrainedClassMethods` is on
by GHC 04 Mar '15

04 Mar '15

#10118: No ambiguity check when `ConstrainedClassMethods` is on -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1-rc2 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: #7854 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following program is wrongfully accepted when `ConstrainedClassMethods` is on: {{{#!hs module ShouldFail where class Foo a where op :: Eq b => a -> Int }}} I have a fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10118> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10119: Class methods must always mention the class variable
by GHC 04 Mar '15

04 Mar '15

#10119: Class methods must always mention the class variable -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1-rc2 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: #7854, #10118 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- As mentioned in comment:9:ticket:7854, GHC wrongfully accepts the following program. It should reject it, because `op` doesn't mention any type variables of `Foo` (the method context doesn't count). {{{#!hs module ShouldFail where class Foo a where op :: Eq a => Int }}} I'm working on it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10119> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10102: GHC inlines past lambda in do-notation
by GHC 04 Mar '15

04 Mar '15

#10102: GHC inlines past lambda in do-notation -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hi, a friend of mine discovered this weird behaviour: The program, when run on the attached file, takes quite some time. {{{ import System.IO import Control.Monad import qualified Data.Map as M main :: IO () main = do n <- read `fmap` getLine q <- read `fmap` getLine mts <- replicateM n $ do [a,b] <- words `fmap` getLine return (a,b) let mtdb2 = M.fromList mts --M.null mtdb2 `seq` return () replicateM_ q $ do a <- getLine print $ M.lookup a mtdb2 return () }}} But if I uncomment the use of `mtdb2` outside the replicate, it runs fast. My conclusion is that GHC inlines `mtdb2` into the body of the loop, repeating the construction of the map over and over. If `forM [1..q] $ \_ -> do` is used instead, this does not happen – probably because GHC does _not_ inline past that lambda. (I didn’t attempt to understand the core yet) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10102> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[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