August 2015 - ghc-tickets

[GHC] #10172: Cross-platform sed
by GHC 11 Nov '15

11 Nov '15

#10172: Cross-platform sed -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build | Version: 7.11 System | Operating System: Solaris Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It's quite easy to accidentally use GNU extensions in sed expressions, which means Solaris builds start failing. See https://phabricator.haskell.org/D740 for an example. What should we do? Here are a few possibilities: * Force use of POSIX sed with `--posix` flag. I haven't tested, but maybe this won't work if Solaris sed chokes on the `--posix`. Alternately, use `$(SED)` and add `--posix` only if it's supported * Detect GNU sed in autoconfigure and use `$(SED)` in all Makefile scripts * Stop using sed in the scripts for something else I don't know if this admonition applies to other random POSIX tools we use. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10172> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9988: Remove fun_id, is_infix from FunBind, as they are now in Match
by GHC 11 Nov '15

11 Nov '15

#9988: Remove fun_id, is_infix from FunBind, as they are now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- One of the changes Phab:D538 introduced is to add m_fun_id_infix to Match {{{#!hs data Match id body = Match { m_fun_id_infix :: (Maybe (Located id,Bool)), -- fun_id and fun_infix for functions with multiple equations -- only present for a RdrName. See note [fun_id in Match] m_pats :: [LPat id], -- The patterns m_type :: (Maybe (LHsType id)), -- A type signature for the result of the match -- Nothing after typechecking m_grhss :: (GRHSs id body) } deriving (Typeable) }}} This was done to track the individual locations and fixity of the fun_id for each of the defining equations for a function when there are more than one. For example, the function (&&&) is defined with some prefix and some infix equations below. {{{#!hs (&&& ) [] [] = [] xs &&& [] = xs ( &&& ) [] ys = ys }}} This means that the fun_id / is_infix is now superfluous in the FunBind. This has not been removed as a potentially risky change just before 7.10 RC2, and so must be done after. This ticket captures that task. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9988> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #10583: Chaos in Lexeme.hs
by GHC 09 Nov '15

09 Nov '15

#10583: Chaos in Lexeme.hs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I've been looking at the `Lexeme` module (in `basicTypes`), where -- as far as I can tell -- utter chaos reigns. (Full disclosure: I wrote this module some time ago, inheriting its code from various places. But I clearly did a poor job of it.) Here is a sampling of the chaos: * `isLexConSym` claims to recognize type and data constructor infix symbols. But it requires symbols to start with a `:` (or be `->`). This is out-of-date with respect to the change in type constructor infix symbols in 7.6(?), which now do not need to start with a `:`. * `isVarSymChar` and `okSymChar` both purport to recognize characters that are valid parts of symbolic identifiers. But they have entirely different, unrelated implementations. These should be the '''same''' function, I believe. * The `notFollowedBySymbol` function defined in `parser/Lexer.x` overlaps with the functions above. But it has a '''third''' implementation, different than either of these other two. * The `isLexXXX` functions all just look at first characters, except for `isLexVarSym`, which looks at all characters. There is a reason for this -- that GHC-generated names start with a `$` but should be printed prefix -- but I'm not sure I buy it. Is it sufficient to look at the first two characters instead of the first one? I'm happy to make the code changes around this, but I need some advice from someone who has more knowledge about both Haskell's lexical structure and quite possibly Unicode. Happily, the function in `Lexeme` are not used much. But it would be awfully nice if they did the right thing when they are used. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10583> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10633: GHCi segfaults on arm
by GHC 07 Nov '15

07 Nov '15

#10633: GHCi segfaults on arm ---------------------------------+------------------------------- Reporter: Thra11 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: arm | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------+------------------------------- I define a data type: {{{#!hs data Tree a = Leaf a | Tree { left :: Tree a , right :: Tree a } deriving Show }}} Then I create a few named trees: {{{#!hs testTree0 = Leaf 0 testTree1 = Tree (Leaf 0) (Leaf 0) testTree2 = Tree testTree0 testTree0 testTree3 = Tree testTree1 testTree1 testTree4 = Tree (Tree (Leaf 0) (Leaf 0)) (Tree (Leaf 0) (Leaf 0)) }}} This segfaults in GHCi (works fine with non-interactive GHC): {{{#!hs main = print testTree3 }}} == Notes == * testTree3 and testTree4 represent the same tree, constructed in different ways. However, testTree3 segfaults when it tries to print the second testTree1; testTree4 does not. * entering 'print testTree1' twice segfaults, but only if it is twice in a row. * strangely enough, printing testTree4 repeatedly does not segfault. * printing testTree0 many times in a row doesn't segfault either. * printing testTree2 segfaults. It seems to be something to do with repetition or reevaluation of the same named structure. I haven't yet managed to determine whether the print is relevant or whether it's forcing the evaluation of the data structure that causes the segfault (Can't remember how to force a list but discard the result). I have attached the the output from running ghci with +RTS -Di. Let me know if there's anything else I should try. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10633> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9591: Add custom "Wiki" field in Trac
by GHC 06 Nov '15

06 Nov '15

#9591: Add custom "Wiki" field in Trac -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I want to request a new custom field to Trac called "Wiki page"? Tickets that are about implementing a larger feature have an accompanying wiki page that summarizes the design. It would help my workflow if I could just get to that wiki page from the top of a Trac ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9591> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10435: catastrophic exception-handling disablement on Windows Server 2008 R2
by GHC 04 Nov '15

04 Nov '15

#10435: catastrophic exception-handling disablement on Windows Server 2008 R2 -------------------------------------+------------------------------------- Reporter: malcolmw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.1 System | Operating System: Windows Keywords: windows, | Type of failure: Runtime crash exceptions | Blocked By: Architecture: x86 | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- We have found a very strange RTS bug that only manifests on some Windows machines, running Windows Server 2008 R2. It does not occur on our Windows 7 machines. We are not sure whether the installed version of Visual C runtime system matters. The context is a ghc-compiled executable, that calls a function from a C++ DLL. The C++ function throws an exception internally, then catches it, and returns normally. The symptom of the bug is that, from ghc-7.8.1 onwards, including ghc-7.10.1, the C++ exception is not caught by the C++ code, but terminates the program catastrophically, with exit code 127. When the Haskell executable is compiled by ghc-7.2.3 or before, the bug does not happen. If, instead of having the main function in Haskell, we write a wrapper main function in C++, that calls the Haskell from a DLL (and the Haskell then calls back into C++), the bug does not happen. Hence, we surmise there is some ghc RTS initialisation that is specific to Windows, that deals with exception handling, and that is incorrect for certain versions of Windows. Attached to the ticket, please find (a) a C++ module, which exports a single function that throws an exception and catches it; (b) a Haskell module which imports the C++ via the FFI, and calls it; (c) a build script which compiles the C++ to a DLL, using the MSVC compiler, compiles the Haskell with ghc, and links them together. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10435> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #10736: threadWaitRead/registerFd unusable
by GHC 03 Nov '15

03 Nov '15

#10736: threadWaitRead/registerFd unusable -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The following program: {{{ module Main where import System.Posix.IO import GHC.Event main = do Just mgr <- getSystemEventManager fd <- openFd "/tmp/bleh" ReadOnly Nothing defaultFileFlags { nonBlock = True } key <- registerFd mgr (\_ _ -> putStrLn "hello") fd evtRead MultiShot return () }}} fails with: {{{ *** Exception: modifyFdOnce: permission denied (Operation not permitted) }}} Since `threadWaitRead` and family are implemented in terms of `registerFd`, they also fail with the same error. Perhaps I am misunderstanding how to use this function, but in this case the conditions that must hold true regarding file descriptors should be documented somewhere. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10736> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10370: Compile time regression in OpenGLRaw
by GHC 26 Oct '15

26 Oct '15

#10370: Compile time regression in OpenGLRaw -------------------------------------+------------------------------------- Reporter: michalt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- As reported by Paolo Veronelli: Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible with -O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host. The file making memory explode is Graphics.Rendering.OpenGL.Raw.Functions. With -O0 it uses 600 MB. The file is really huge, but I could compile it with prior versions of ghc. I've had a look and indeed the file takes way more memory to compile with HEAD. Looking at the heap profiles, it seems that the problem is in GHC itself (space leak somewhere?). I'll attach the heap profiles (from compiling the single module itself, i.e., `touch`ing the file and running prof GHC on it). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10370> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #10242: Multiple constraint wildcards allowed with PartialTypeSignatures
by GHC 22 Oct '15

22 Oct '15

#10242: Multiple constraint wildcards allowed with PartialTypeSignatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple PartialTypeSignatures | Type of failure: GHC accepts Architecture: | invalid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The [https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures wiki] states that > As a single extra-constraints wildcard is enough to infer any number of constraints, only one is allowed in a type signature and it should come last in the list of constraints. However the following program compiles with GHC 7.10.1 {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} f :: (Eq a, _, _) => a -> a -> Bool f x y = x == y }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10242> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10428: GHC cannot match representations using Coercible constraint
by GHC 22 Oct '15

22 Oct '15

#10428: GHC cannot match representations using Coercible constraint -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following code compiles in 7.8.4 but fails in 7.10.1: {{{#!hs import Data.Coerce coerceNewtype :: (Coercible (o r) (n m' r)) => [o r] -> [n m' r] coerceNewtype = coerce }}} with the error {{{ Couldn't match representation of type ‘n m' r’ with that of ‘o r’ arising from trying to show that the representations of ‘[o r]’ and ‘[n m' r]’ are the same Relevant role signatures: type role [] representational }}} However, the following compiles: {{{#!hs {-# LANGUAGE TypeFamilies #-} import Data.Coerce coerceNewtype :: (Coercible a b, a ~ (o r), b ~ (n m' r)) => [o r] -> [n m' r] coerceNewtype = coerce }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10428> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8