November 2015 - ghc-tickets

Re: [GHC] #4863: TH crashes if you reify the Name of a dfun
by GHC 10 Nov '15

10 Nov '15

#4863: TH crashes if you reify the Name of a dfun -------------------------------------+------------------------------------- Reporter: guest | Owner: simonpj Type: bug | Status: closed Priority: low | Milestone: ⊥ Component: Template Haskell | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: I agree. This ticket has been fixed over the course of time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4863#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3242: GHCi linker does not correctly locate static libraries under Windows
by GHC 10 Nov '15

10 Nov '15

#3242: GHCi linker does not correctly locate static libraries under Windows ---------------------------------+---------------------------------------- Reporter: jeffz1 | Owner: Phyx- Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: T3242 Blocked By: 3658 | Blocking: Related Tickets: #7097 | Differential Rev(s): Phab:D1455 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * status: new => patch * testcase: => T3242 * differential: => Phab:D1455 * architecture: x86 => Unknown/Multiple -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3242#comment:44> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4931: hsc2hs emits invalid OPTIONS_GHC pragmas
by GHC 09 Nov '15

09 Nov '15

#4931: hsc2hs emits invalid OPTIONS_GHC pragmas -------------------------------------+------------------------------------- Reporter: awson | Owner: thomie Type: bug | Status: patch Priority: low | Milestone: 8.0.1 Component: hsc2hs | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: driver/T4931 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1452 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch Comment: The patch in Phab:D1452 doesn't handle `#define FOO "bar \"baz\""` (comment:8), but it does handle the example from the description: `#define FOO "bar baz"`. I still don't know if emitting `{-# OPTIONS_GHC -optc-DFOO=... #-}` makes sense at all, but oh well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4931#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4931: hsc2hs emits invalid OPTIONS_GHC pragmas
by GHC 09 Nov '15

09 Nov '15

#4931: hsc2hs emits invalid OPTIONS_GHC pragmas -------------------------------------+------------------------------------- Reporter: awson | Owner: thomie Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: hsc2hs | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: driver/T4931 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1452 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => * owner: terrelln => thomie * differential: => Phab:D1452 * testcase: => driver/T4931 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4931#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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 09 Nov '15

09 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] #11044: Parse error on empty multi-line deprecation warnings
by GHC 08 Nov '15

08 Nov '15

#11044: Parse error on empty multi-line deprecation warnings -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Bug #3303 introduced support for multi-line deprecation messages, with syntax {{{ {-# DEPRECATED someFunction ["One line", "another line"] #-} }}} The following gives a parse error, though: {{{ {-# DEPRECATED someFunction [] #-} }}} I think that it would be reasonable to treat this case as {{{ {-# DEPRECATED somefunction "" #-} }}} For motivation: we ran into this problem when writing bindings to external libraries. The API description for the original library includes deprecation info, with the deprecation messages sometimes spanning multiple lines, so it was convenient to use the list syntax above when generating the Haskell wrappers. But the parse error forced us to special case the case of no deprecation message. We can easily do this, of course, but perhaps the restriction to non-empty lists was not intentional? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11044> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11057: toIfaceIdDetails trace statement catches PatSynBuilder
by GHC 08 Nov '15

08 Nov '15

#11057: toIfaceIdDetails trace statement catches PatSynBuilder -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- hvr reported this `pprTrace` message showing up during a GHC build, {{{ [ 73 of 212] Compiling GHC.Exception ( GHC/Exception.hs, dist/build/GHC/Exception.o ) toIfaceIdDetails [PatSynBuilder] }}} I believe this is due to mpickering's Phab:D1152, which introduced the `PatSynBuilder` constructor without handling it in `toIfaceIdDetails`. Given that things appear to work, I would guess we want to handle it with, {{{ toIfaceIdDetails PatSynBuilder = IfVanillaId }}} but I'm not certain. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11057> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[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

Re: [GHC] #3242: GHCi linker does not correctly locate static libraries under Windows (was: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL))
by GHC 07 Nov '15

07 Nov '15

#3242: GHCi linker does not correctly locate static libraries under Windows ---------------------------------+----------------------------- Reporter: jeffz1 | Owner: Phyx- Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: #7097 | Differential Rev(s): Wiki Page: | ---------------------------------+----------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3242#comment:43> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0