September 2015 - ghc-tickets

[GHC] #10216: Allow arr ∧ (first ∨ (***)) as minimal definition of Arrow instance
by GHC 13 Oct '15

13 Oct '15

#10216: Allow arr ∧ (first ∨ (***)) as minimal definition of Arrow instance -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.1 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10216> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10831: DeriveFunctor not capable of deriving when wrapping Either
by GHC 13 Oct '15

13 Oct '15

#10831: DeriveFunctor not capable of deriving when wrapping Either -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: MacOS X Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- GHC can derive Functor for Okay, but rejects the equivalent Bad. {{{#!hs {-# LANGUAGE DeriveFunctor #-} data Okay f g a b = Inl (f a b) | Inr (g a b) deriving (Functor) newtype Bad f g a b = Bad (Either (f a b) (g a b)) deriving (Functor) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10831> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #10611: Runtime crash while running psc
by GHC 12 Oct '15

12 Oct '15

#10611: Runtime crash while running psc -------------------------------------+------------------------------------- Reporter: qxjit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Got a runtime crash while running the purescript compiler: psc: internal error: evacuate(static): strange closure type 6647784 (GHC version 7.8.3 for x86_64_unknown_linux) As yet I have not be able to reproduce it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10611> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10733: Improving the error message for type variable ambiguity
by GHC 12 Oct '15

12 Oct '15

#10733: Improving the error message for type variable ambiguity -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This is a summary of a [https://mail.haskell.org/pipermail/ghc- devs/2015-August/009522.html discussion on ghc-devs]. The current message when a type variable is ambiguous could use a little rewording to improve its friendliness towards the user. Currently, it looks like this: {{{ No instance for (Foldable t0) arising from a use of ‘elem’ The type variable ‘t0’ is ambiguous Relevant bindings include valid :: t0 Char (bound at …) Note: there are several potential instances: instance Foldable (Either a) -- Defined in ‘Data.Foldable’ instance Foldable Data.Proxy.Proxy -- Defined in ‘Data.Foldable’ instance GHC.Arr.Ix i => Foldable (GHC.Arr.Array i) -- Defined in ‘Data.Foldable’ ...plus three others }}} The focus seems to be on "No instance", which, while technically correct, does not usually lead to the correct solution of the problem. In particular, the "type variable is ambiguous" does not appear until the 2nd or 3rd line, making it easy to miss, which may lead to confusion with other kinds of "No instance" errors that have a similar leading sentence. There are two ways to fix this error usually: * By defining `instance Foldable t0`, but this is rarely what the user wants. * By fixing the ambiguity using a type annotation. Given that the latter seems to be a more likely cause, it may help if the error message were rewritten to prioritize that, while also leaving the first solution open if the user really knows what they are doing. Therefore, it is suggested that the message should reword in a way similar to this: {{{ Ambiguous type variable ‘t0’ arising from a use of ‘elem’ caused by the lack of an instance ‘(Foldable t0)’ Relevant bindings include valid :: t0 Char (bound at …) Either use a type annotation to specify what ‘t0’ should be based on these potential instance(s): instance Foldable (Either a) -- Defined in ‘Data.Foldable’ instance Foldable Data.Proxy.Proxy -- Defined in ‘Data.Foldable’ instance GHC.Arr.Ix i => Foldable (GHC.Arr.Array i) ... plus three others and possibly more from other modules that the compiler has not yet encountered or define the required instance ‘(Foldable t0)’ }}} which puts the emphasis on "ambiguous type variable" in the first few words while also outlining the possible solutions for the user and reminding them of the open-world assumption. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10733> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10913: deprecate and then remove -fwarn-hi-shadowing
by GHC 10 Oct '15

10 Oct '15

#10913: deprecate and then remove -fwarn-hi-shadowing -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I realized that the flag is not used in the compiler at all, and @slyfox realized that the flag was last used in 2006. He also found out that there are 355 packages in the Hackage that use this useless flag. So we should maybe first deprecate it and remove it later. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10913> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10571: GHC 7.10.1 segfaults when shiftL-ing Integers by negative amounts
by GHC 10 Oct '15

10 Oct '15

#10571: GHC 7.10.1 segfaults when shiftL-ing Integers by negative amounts -------------------------------------+------------------------------------- Reporter: anders_ | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- For numbers other than 1, anyway. {{{ $ ghc -e 'Data.Bits.shiftL 1 (-1)' -9223372036854775808 $ ghc -e 'Data.Bits.shiftL 2 (-1)' zsh: segmentation fault ghc -e 'Data.Bits.shiftL 2 (-1)' $ ghc -e 'Data.Bits.shiftL 100 (-1)' zsh: segmentation fault ghc -e 'Data.Bits.shiftL 100 (-1)' }}} This also happens with a compiled program. It doesn't with {{{shiftR}}} in either case though. Side notes: - On OS X, when the first operand is also negative, I get a {{{bus error}}} instead of a {{{segmentation fault}}}. Linux gives {{{segmentation fault}}} on both. - On Linux, you have to use {{{ghci}}} instead of {{{-e}}}, for some (probably unrelated?) reason). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10571> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9319: nofib-analyze doesn’t provide per-benchmark compile time/alloc numbers
by GHC 08 Oct '15

08 Oct '15

#9319: nofib-analyze doesn’t provide per-benchmark compile time/alloc numbers -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.8.2 suite | Differential Revisions: Keywords: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- The compile time and allocation numbers calculated by nofib are only available per module. While this is useful to find the cause of problems, it would be nice if these numbers were also accumulated for each benchmark, for easy of general analysis and uniformity, especially with automated monitoring of benchmark numbers. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9319> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10153: GHC mode for converting files to explicit layout
by GHC 08 Oct '15

08 Oct '15

#10153: GHC mode for converting files to explicit layout -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple (Parser) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- One area where GHC is a little less friendly to newcomers is its Byzantine whitespace layout rules. Once you've gotten used to using GHC you can usually get what you want by abiding certain style, but before then it might be useful to see how GHC is inserting semicolons to your document. I don't think this would be too hard to do. The idea is to get the token stream and look for virtual curlies with no location. Once you have a list of them, you can go over the original buffer again and insert a brace or semicolon whenever you see a token like this. Might be a good beginner task. This function would also be useful for debugging layout, since knowing if semicolons are being inserted is useful. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10153> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9058: System.IO.openTempFile does not scale
by GHC 07 Oct '15

07 Oct '15

#9058: System.IO.openTempFile does not scale ------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- In search of a bug in darcs http://bugs.darcs.net/issue2364 i've notice very bad property of openTempFile: it's pattern is very predictable and has O(n^2) of already created temp files. Predictability allows very fun bugs survive in buggy programs, like: {{{ thread1: (fn, fh) <- openTempFile "." "hello" renameFile fn "something" -- some time after when (some_rare_buggy_condition) $ -- oops, reused temp name, but too late, other thread killed it writeFileFile fn thread2: (fn, fh) <- openTempFile "." "hello" workWithFn fn -- nobody should touch it, right? }}} It's _very_ hard to debug data corruption when all temp files are named "foo${pid}" and sometimes "foo${pid+1}". And more serious bug: the more threads you have trying to create similar temps performance drops significantly: Attached program shows the following numbers: {{{ $ time ./bench-temps same 2000 real 0m2.795s user 0m1.516s sys 0m1.190s $ time ./bench-temps diff 2000 real 0m0.161s user 0m0.043s sys 0m0.115s }}} It's O(N^2) growing open() storm. https://github.com/ghc/ghc/blob/master/libraries/base/System/IO.hs#L465 {{{ FileExists -> findTempName (x + 1) }}} This is the source of the problem. I'd suggest always using random name for it. For portability reasons I suggest adding at least insecure random '''rand()''' value from C library. That way we will succeed in opening temp file at the first attempt. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9058> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8364: equip GHC with an accurate internal model of floating point
by GHC 07 Oct '15

07 Oct '15

#8364: equip GHC with an accurate internal model of floating point ----------------------------------------------+---------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more than a week) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- currently there really isn't a systematic / portable story for doing compile time reduction / evaluation for floating point numbers. there are some folks in the larger haskell community who are working on high precision soft float implementations / modelling. Once that work becomes available, might be worth exploring having something like that for doing controlled high precision evaluation of intermediate expressions in ghc proper. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8364> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4