April 2017 - ghc-tickets

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 11 Apr '17

11 Apr '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): Replying to [comment:66 bgamari]: > > If we add a new closure type for `ByteArray#`, could it be used in runtime also? > > I'm not sure I follow the suggestion here. What do you mean by "used in the runtime"? I mean can we change 'ByteArray#' 's representation into just length and content (removing the header)? I think that's not possible due to GC expect to see an uniform heap object representation, but i'm not sure there's no other way to make it work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:67> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4154: Deadlock in Chan module
by GHC 11 Apr '17

11 Apr '17

#4154: Deadlock in Chan module -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: libraries/base | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mitar): Not sure if I am able to do so either. :-( -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4154#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8025: -fno-code and Template Haskell are incompatible
by GHC 10 Apr '17

10 Apr '17

#8025: -fno-code and Template Haskell are incompatible -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): duog, if you could push the test scripts (or perhaps just the original patches) to a GitHub branch and include a link in the Diff description that would be great. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8025#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4154: Deadlock in Chan module
by GHC 10 Apr '17

10 Apr '17

#4154: Deadlock in Chan module -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: libraries/base | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:9 mitar]: > What about my proposal: > > The only case where I have been using `isEmptyChan` was in my version of non-blocking `readChan`, returning Maybe. Is it possible to define instead of `isEmptyChan` some non-blocking version of `readChan` with `tryTakeMVar` and `tryPutMVar`? Out of curiosity, why not move to STM if you need these sorts of operations? I think the proposal is fine (assuming it's possible to implement safely; I am not familiar with the implementation of `Chan`). Do you want to put together a patch? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4154#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13550: -ddump-splices doesn't parenthesize type/data families correctly in 8.2.1
by GHC 10 Apr '17

10 Apr '17

#13550: -ddump-splices doesn't parenthesize type/data families correctly in 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #13199 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The pretty-printed code which `-ddump-splices` has regressed since 8.0. If you compile this code: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where $([d| type family Foo a b type instance Foo (Maybe a) b = Either (Maybe a) (Maybe b) data family Bar a b data instance Bar (Maybe a) b = BarMaybe (Maybe a) (Maybe b) |]) }}} with GHC 8.0.2, you get this: {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(6,3)-(11,6): Splicing declarations [d| type family Foo_a13C a_a13G b_a13H data family Bar_a13B a_a13E b_a13F data instance Bar_a13B (Maybe a_a13I) b_a13J = BarMaybe_a13D (Maybe a_a13I) (Maybe b_a13J) type instance Foo_a13C (Maybe a_a13K) b_a13L = Either (Maybe a_a13K) (Maybe b_a13L) |] ======> type family Foo_a3O6 a_a3O9 b_a3Oa type instance Foo_a3O6 (Maybe a_a3Ob) b_a3Oc = Either (Maybe a_a3Ob) (Maybe b_a3Oc) data family Bar_a3O7 a_a3Od b_a3Oe data instance Bar_a3O7 (Maybe a_a3Of) b_a3Og = BarMaybe_a3O8 (Maybe a_a3Of) (Maybe b_a3Og) }}} Looks good. But in GHC 8.2.1, the output of `-ddump-splices` lacks many sets of parentheses which are necessary for correctness! {{{ GHCi, version 8.2.0.20170403: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(6,3)-(11,6): Splicing declarations [d| type family Foo_a1ty a_a1tC b_a1tD data family Bar_a1tx a_a1tA b_a1tB type instance Foo_a1ty (Maybe a_a1tG) b_a1tH = Either (Maybe a_a1tG) (Maybe b_a1tH) data instance Bar_a1tx (Maybe a_a1tE) b_a1tF = BarMaybe_a1tz (Maybe a_a1tE) (Maybe b_a1tF) |] ======> type family Foo_a4ia a_a4id b_a4ie type instance Foo_a4ia Maybe a_a4if b_a4ig = Either (Maybe a_a4if) (Maybe b_a4ig) data family Bar_a4ib a_a4ih b_a4ii data instance Bar_a4ib Maybe a_a4ij b_a4ik = BarMaybe_a4ic Maybe a_a4ij Maybe b_a4ik }}} This pops up both in the arguments to `type instance Foo ...` and `data instance Bar ...`, as well as the arguments to the data constructor `BarMaybe`. cc'ing alanz, since I suspect this is related to #13199. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13550> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #4154: Deadlock in Chan module
by GHC 10 Apr '17

10 Apr '17

#4154: Deadlock in Chan module -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: libraries/base | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mitar): What about my proposal: The only case where I have been using `isEmptyChan` was in my version of non-blocking `readChan`, returning Maybe. Is it possible to define instead of `isEmptyChan` some non-blocking version of `readChan` with `tryTakeMVar` and `tryPutMVar`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4154#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 10 Apr '17

10 Apr '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > If we add a new closure type for `ByteArray#`, could it be used in runtime also? I'm not sure I follow the suggestion here. What do you mean by "used in the runtime"? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:66> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13371: instance selection too eager
by GHC 10 Apr '17

10 Apr '17

#13371: instance selection too eager -------------------------------------+------------------------------------- Reporter: aavogt | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (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: -------------------------------------+------------------------------------- I see a regression in 8.0.2: the `g_f'` definition is rejected. The error goes away if I do one of: * -XNoMonoLocalBinds * -XNoPolyKinds * pasting the inferred type of `g_f` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13371> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13509: Perplexing type error
by GHC 10 Apr '17

10 Apr '17

#13509: Perplexing type error -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- The `fast-digits` package fails to build with 8.2.0-rc1, {{{ [1 of 2] Compiling Data.FastDigits.Internal ( src/Data/FastDigits/Internal.hs, dist/build/Data/FastDigits/Internal.o ) src/Data/FastDigits/Internal.hs:42:34: error: • Couldn't match a lifted type with an unlifted type Expected type: Word# -> (# Word#, Word# #) Actual type: Word# -> (# Word#, Word# #) • In the expression: go pw2 In a pattern binding: (# n, pw2n #) = go pw2 In the expression: let (# n, pw2n #) = go pw2 in case timesWord2# pw pw2n of (# 0##, pw2n1 #) -> (# n `timesWord#` 2## `plusWord#` 1##, pw2n1 #) _ -> (# n `timesWord#` 2##, pw2n #) | 42 | -> let (# n, pw2n #) = go pw2 in | ^^^^^^ src/Data/FastDigits/Internal.hs:43:33: error: • Couldn't match a lifted type with an unlifted type When matching the kind of ‘Word#’ • In the second argument of ‘timesWord2#’, namely ‘pw2n’ In the expression: timesWord2# pw pw2n In the expression: case timesWord2# pw pw2n of (# 0##, pw2n1 #) -> (# n `timesWord#` 2## `plusWord#` 1##, pw2n1 #) _ -> (# n `timesWord#` 2##, pw2n #) | 43 | case timesWord2# pw pw2n of | ^^^^ src/Data/FastDigits/Internal.hs:44:37: error: • Couldn't match a lifted type with an unlifted type When matching the kind of ‘Word#’ • In the first argument of ‘timesWord#’, namely ‘n’ In the first argument of ‘plusWord#’, namely ‘n `timesWord#` 2##’ In the expression: n `timesWord#` 2## `plusWord#` 1## | 44 | (# 0##, pw2n1 #) -> (#n `timesWord#` 2## `plusWord#` 1##, pw2n1 #) | ^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13509> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #8025: -fno-code and Template Haskell are incompatible
by GHC 10 Apr '17

10 Apr '17

#8025: -fno-code and Template Haskell are incompatible -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): Thanks Ben, I've just posted a diff moments before I saw this. I have abandoned your D3427 in favour of D3441. I see that you have removed my bash scripts. I'll remove them from D3441, let me know if you'd like me to make them available elsewhere. My github fork will not be a very reliable place to get them as it's likely to get rebased a lot. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8025#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0