- ghc-tickets - Haskell.org

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

[GHC] #10955: GHC on windows does not resolve DLL dependencies
by GHC 07 Nov '15

07 Nov '15

#10955: GHC on windows does not resolve DLL dependencies -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime | Version: 7.10.2 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC does not correctly tell the Windows Loader how to handle dependencies to dll's that are not on the standard windows load path: 1. The directory from which the application loaded. 2. The current directory. 3. The system directory. Use the `GetSystemDirectory` function to get the path of this directory. 4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched. 5. The Windows directory. Use the `GetWindowsDirectory` function to get the path of this directory. 6. The directories that are listed in the `PATH` environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path. So what this means is given two DLLs `A` and `B` and `B` depending on `A`. If we put both DLLs into a new folder `bin` and then call GHC with: `ghc -L$(PWD)/bin -lB` the loading will fail as the Windows loader will try to load the dependency of `B` and fail since it cannot find `A`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10955> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #4837: Template Haskell does not work in a profiled compiler.
by GHC 07 Nov '15

07 Nov '15

#4837: Template Haskell does not work in a profiled compiler. -------------------------------------+------------------------------------- Reporter: benl | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Profiling | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4837#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0