October 2017 - ghc-tickets

[GHC] #13707: xmobar crashes with segmentation faults?
by GHC 25 Oct '17

25 Oct '17

#13707: xmobar crashes with segmentation faults? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Markus Trippelsdorf on `ghc-devs` reports that 8.2.1-rc2 produces crashing `xmobar` executables. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13707> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #14384: real numbers, digits after the decimal point - digits of precision
by GHC 24 Oct '17

24 Oct '17

#14384: real numbers, digits after the decimal point - digits of precision -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- the results from computation should have eleven digits after the decimal point for real numbers. (11 digits of precision) it seems reasonable.\\ instead of: {{{ Prelude> (16.0/0.00002)**2.1 2.491661103847512e12 }}} this is better:\\ {{{ 2.49166110385e12 }}} it should be noted that a lot of computing system uses this precision. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14384> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14380: Compile error for PatternSynonyms together with OverloadedLists
by GHC 24 Oct '17

24 Oct '17

#14380: Compile error for PatternSynonyms together with OverloadedLists -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE OverloadedLists #-} {-# LANGUAGE PatternSynonyms #-} data Foo = Foo [Int] pattern Bar :: Foo pattern Bar = Foo [] }}} This code results in a cryptic compilation error: {{{ $ ghc main.hs [1 of 1] Compiling Main ( main.hs, main.o ) main.hs:7:19: error: • Couldn't match expected type ‘[a0] -> [Int]’ with actual type ‘[GHC.Exts.Item Int]’ • This rebindable syntax expects a function with two arguments, but its type ‘Int -> [GHC.Exts.Item Int]’ has only one In the first argument of ‘Foo’, namely ‘[]’ In the expression: Foo [] | 7 | pattern Bar = Foo [] | ^^ }}} As soon as `OverloadedLists` is removed, this error goes away. In itself the problem isn't too critical, but very unexpected. I got above error with GHC 8.0 and 8.2, so decided to check it with current version as well: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.3.20171020 }}} Looking a bit more into `PatternSynonyms` extension I was able to work around this by declaring an explicit bidirectional pattern, which, surprisingly, solved the problem: {{{#!hs pattern Bar :: Foo pattern Bar <- Foo [] where Bar = Foo [] }}} If fixing this issue is too much trouble than it is worth, than at least a mention about it in documentation will be helpful. Out of curiosity I also tried it with `String`, which did not trigger this error and compiled just fine: {{{#!hs {-# LANGUAGE OverloadedLists #-} {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE PatternSynonyms #-} data Foo = Foo [Char] pattern Bar :: Foo pattern Bar = Foo "" }}} PS. Even if this issue is closed, searching the internet for the error message will now at least return some info. :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14380> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14383: Allocation in VS up 500%
by GHC 23 Oct '17

23 Oct '17

#14383: Allocation in VS up 500% -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Somewhere in between the commits fee253fc and 99c61e22 nofib’s `VS` benchmark has allocations increased by 500%. perf.haskell.org is currently defuct (linker errors due to recent changes to the ffi stuff, I believe Moritz is trying to find that out), so I cannot just look there to see which commit broke it. But maybe someone feels like bisecting this. If not maybe perf.haskell.org will be able to tell us once its fixed (although keeping up with GHC commits there is a bit of a pain these days.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14383> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13356: gmp/ghc.mk's use of TARGETPLATFORM and BUILDPLATFORM is wrong
by GHC 23 Oct '17

23 Oct '17

#13356: gmp/ghc.mk's use of TARGETPLATFORM and BUILDPLATFORM is wrong -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `libraries/integer-gmp/gmp/ghc.mk` invokes `libgmp`'s configure script with the options {{{ --host=$(TARGETPLATFORM) --build=$(BUILDPLATFORM) }}} Using `TARGETPLATFORM` is wrong, as it is the GHC-munged target triple. For example if the triple passed to the top-level configure script was `--target=aarch64-apple-darwin14` (for iPhone), `TARGETPLATFORM` will be `aarch64-apple-ios`, which `configure` does not understand. Instead of `TARGETPLATFORM` we should use `TargetPlatformFull`. I don't think we have a corresponding variable for `BUILDPLATFORM`, so we should add one if it's important. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13356> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #3919: Or-patterns as GHC extension
by GHC 23 Oct '17

23 Oct '17

#3919: Or-patterns as GHC extension -------------------------------------+------------------------------------- Reporter: BjornEdstrom | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Proposal link: https://github.com/ghc-proposals/ghc-proposals/pull/43 (waiting for committee review) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3919#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4020: Please consider adding support for local type synonyms
by GHC 23 Oct '17

23 Oct '17

#4020: Please consider adding support for local type synonyms -------------------------------------+------------------------------------- Reporter: nr | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 6.12.2 checker) | Resolution: | Keywords: type synonym Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:15 Iceland_jack]: > Allowing local data declarations would be more useful (local pattern synonyms even more so) Those are two further proposals. Let's not muddle them up on one ticket. (Do consider raising them as github proposals; but it'll need more than three words to explain what you mean.) It would be worth asking first on StackOverflow or the cafe why Haskell doesn't currently do "local" anything in the type system. You can use export/import settings to make the declared names local to a module. But I guess that's not what you're talking about(?) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4020#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4020: Please consider adding support for local type synonyms
by GHC 22 Oct '17

22 Oct '17

#4020: Please consider adding support for local type synonyms -------------------------------------+------------------------------------- Reporter: nr | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 6.12.2 checker) | Resolution: | Keywords: type synonym Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Allowing local data declarations would be more useful (local pattern synonyms even more so) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4020#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4020: Please consider adding support for local type synonyms
by GHC 22 Oct '17

22 Oct '17

#4020: Please consider adding support for local type synonyms -------------------------------------+------------------------------------- Reporter: nr | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 6.12.2 checker) | Resolution: | Keywords: type synonym Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [ticket:4020 nr]: > I would really like to be able to put a type synonym in a where clause. Please explain why you couldn't declare the synonym at top level, as usual. Do you want the synonym to work wherever this module gets imported into? How will that go if it's nested? > > For an example use case, please see line 202 of the attachment. Please provide a more focussed example. Line 202 of 707. Do you really need 707 lines to explain the need? I suggest you make a proposal through the github process. (Or those who've recently added themselves to the ticket do.) Type synonyms are top level/global because all types and classes are. Otherwise type solving might be incoherent. -1 from me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4020#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14376: Testsuite contains "ddump-cps-cmm"
by GHC 21 Oct '17

21 Oct '17

#14376: Testsuite contains "ddump-cps-cmm" -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- Low hanging: change those to "ddump-cmm-cps". Run test suite. Implement warning for non-recognised dump flags. -------- IRC ---------- heisenbug: git grep ddump-cps-cmm | grep -v /tests/ [11:26am] heisenbug: ^^^^ is empty [11:27am] heisenbug: git grep ddump-cmm-cps [11:27am] heisenbug: ^^^^ correct spelling [11:27am] slyfox: should be fixed [11:28am] heisenbug: should I update the tests? [11:28am] slyfox: i'd say yes. do they run and fail? [11:29am] heisenbug: I just found it, cannot say [11:29am] heisenbug: I am researching… [11:30am] heisenbug: strange that the wrong -ddump flags are not rejected… [11:30am] slyfox: 'git log -p -Scps-cmm' shows the flag was renamed in f6f881f09c1ac69be2ae1850cb3067459f623360 [11:31am] heisenbug: but not the tests ? [11:31am] slyfox: maybe they should emit at least a warning. that way tests would fails with stderr rejection [11:31am] slyfox: not the tests [11:31am] heisenbug: absolutely -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14376> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0