- ghc-tickets - Haskell.org

Re: [GHC] #5022: Core Lint error from polymorphic definitions inside arrow rec
by GHC 11 Apr '17

11 Apr '17

#5022: Core Lint error from polymorphic definitions inside arrow rec -----------------------------------+-------------------------------------- Reporter: serpentologist | Owner: ross Type: bug | Status: closed Priority: high | Milestone: 7.4.1 Component: Compiler | Version: 7.0.2 Resolution: fixed | Keywords: Arrows Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: arrows/T5022 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Changes (by simonpj): * keywords: infinite loop => Arrows -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5022#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7071: Refactoring arrows
by GHC 11 Apr '17

11 Apr '17

#7071: Refactoring arrows -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Resolution: fixed | Keywords: Arrows Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Arrows -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7071#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8505: Arrows example error
by GHC 11 Apr '17

11 Apr '17

#8505: Arrows example error ------------------------------------+-------------------------------------- Reporter: pdfrod | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- In the section '''7.15.2. Conditional commands''' of the User's Guide (http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/arrow- notation.html#idp49515792) it is stated that: {{{ proc (x,y) -> if f x y then g -< x+1 else h -< y+2 }}} is translated to: {{{ arr (\ (x,y) -> if f x y then Left x else Right y) >>> (arr (\x -> x+1) >>> f) ||| (arr (\y -> y+2) >>> g) }}} But this translation doesn't seem correct, because the arrows ''g'' and ''h'' are not being used as in the original code (''h'' doesn't appear at all in the translation). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8505> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10582: Tiny bug in lexer around lexing banana brackets
by GHC 11 Apr '17

11 Apr '17

#10582: Tiny bug in lexer around lexing banana brackets -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: low | Milestone: 7.10.3 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: | -------------------------------------+------------------------------------- If I say {{{ {-# LANGUAGE Arrows #-} (|:) :: Int -> Int -> Int (|:) = (+) }}} I get {{{ /Users/rae/temp/Bug.hs:3:3: parse error on input ‘:’ }}} Trying this with other operators, like `(|+)`, works fine. The problem is that `notFollowedBySymbol` in Lexer.x is slightly wrong. I will fix in ongoing (mostly unrelated) work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10582> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

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 11 Apr '17

11 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 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 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 11 Apr '17

11 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 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): 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