June 2015 - ghc-tickets

[GHC] #10061: Remove fun_infix from Funbind, as it is now in Match
by GHC 13 Nov '15

13 Nov '15

#10061: Remove fun_infix from Funbind, as it is now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #9988 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_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, which includes processing these fields through the renamer and beyond. Ticket #9988 introduced these fields into Match through renaming, this ticket it to continue through type checking and then remove it from FunBind completely. The split happened so that #9988 could land in 7.10 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10061> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

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

[GHC] #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images
by GHC 22 Oct '15

22 Oct '15

#10416: GHC 7.10.1 User Guide profiling section 5.4 missing images -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The page https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_guide/prof- heap.html References an image https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_guide/prof_scc which does not render. This URL does render though: https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_guide/prof_scc.png -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10416> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16