October 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] #10942: CPP pragma ignored if top comments and Opt_KeepRawTokenStream
by GHC 12 Nov '15

12 Nov '15

#10942: CPP pragma ignored if top comments and Opt_KeepRawTokenStream -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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 Rev(s): | -------------------------------------+------------------------------------- HaRe sets `Opt_KeepRawTokenStream` to be able to round trip the source code. If we have a module starting {{{#!hs {- A normal comment, to check if we can still pick up the CPP directive after it. -} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE CPP #-} -- Check that we can parse a file which requires CPP module BCpp where bob :: Int -> Int -> Int #if __GLASGOW_HASKELL__ > 704 bob x y = x + y #else bob x y = x + y * 2 #endif }}} then the call to `loadTargets` via the GHC API fails with `SourceError (lexical error at character 'i'` which is the normal error when `#if` is hit and CPP is not enabled. If `Opt_KeepRawTokenStream` is not set it loads without problems. Also, files using CPP but not having a top comment load properly too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10942> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[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] #10870: PPC.Ppr: Shift by 32 bits is not allowed.
by GHC 11 Nov '15

11 Nov '15

#10870: PPC.Ppr: Shift by 32 bits is not allowed. -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: powerpc | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Hi, when compiling `vector-algorithms` on powerpc, I get {{{ [ 7 of 10] Compiling Data.Vector.Algorithms.Tim ( src/Data/Vector/Algorithms/Tim.hs, dist- ghc/build/Data/Vector/Algorithms/Tim.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for powerpc-unknown-linux): PPC.Ppr: Shift by 32 bits is not allowed. }}} I do not get this error on other 32bit architectures. The offending code seems to be {{{ minrun :: Int -> Int minrun n0 = (n0 `unsafeShiftR` extra) + if (lowMask .&. n0) > 0 then 1 else 0 where -- smear the bits down from the most significant bit !n1 = n0 .|. unsafeShiftR n0 1 !n2 = n1 .|. unsafeShiftR n1 2 !n3 = n2 .|. unsafeShiftR n2 4 !n4 = n3 .|. unsafeShiftR n3 8 !n5 = n4 .|. unsafeShiftR n4 16 !n6 = n5 .|. unsafeShiftR n5 32 }}} The call to panic was introduced by Erik in the fix for #5900. Is the code at fault, or the compiler? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10870> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name
by GHC 11 Nov '15

11 Nov '15

#10974: Fix SysTools.readElfSection on platforms where "readelf" have different name -------------------------------------+------------------------------------- Reporter: ony | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: driver/recomp011 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Some linux systems may use target-prefixed names for `binutils`. For example on my Exherbo Linux readelf is named as `x86_64-pc-linux-gnu- readelf`. This leads to errors like: > readelf: createProcess: runInteractiveProcess: exec: does not exist (No such file or directory) To fix this GHC needs to give ability to configure name of this tool (like `SysTools.runSplit` and `SysTools.runCc`) or use `libelf`-like library. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10974> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[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] #11007: Type family injectivity annotations ignored in hs-boot files
by GHC 10 Nov '15

10 Nov '15

#11007: Type family injectivity annotations ignored in hs-boot files -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's the test case: {{{ -- A.hs-boot {-# LANGUAGE TypeFamilies #-} module A where type family Id x = r | r -> x where .. }}} {{{ -- needed to avoid illegal self-import module B where import {-# SOURCE #-} A }}} {{{ {-# LANGUAGE TypeFamilies #-} module A where import B type family Id x = r | r -> x where Id a = a }}} I get {{{ A.hs-boot:6:1: error: Type constructor ‘Id’ has conflicting definitions in the module and its hs-boot file Main module: type family Id x = r :: * | r -> x where Id a = a Boot file: type family Id x :: * }}} Even when declaring an abstract closed type family, it should still be able to be injective. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11007> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[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] #10912: Support for out of the box static linking
by GHC 08 Nov '15

08 Nov '15

#10912: Support for out of the box static linking -------------------------------------+------------------------------------- Reporter: crb002 | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Package | Version: 7.10.2 system | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When running in environments like AWS Lambda you don't have access to basic shared libraries Haskell needs like libgmp, libffi. Need good support for static linked libraries of anything included in a basic GHC distribution. https://github.com/commercialhaskell/stack/issues/1032 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10912> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[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