August 2015 - ghc-tickets

[GHC] #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs
by GHC 19 Oct '15

19 Oct '15

#9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs -------------------------------------+------------------------------------- Reporter: mcandre | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Like many programming language environments, GHC offers a handy `-e` option for evaluating an expression, then returning to the shell. {{{ $ ghc -e '2 + 2' 4 }}} One would expect the interpreter, GHCi, to offer a similar flag, but it surprisingly rejects it. {{{ ghci -e '2 + 2' ghc: on the commandline: cannot use `--interactive' with `-e' Usage: For basic information, try the `--help' option. }}} I think this behavior is quite unintuitive--when I pass `-e <exp>` to ghci, or pass `--interactive -e <exp>` to ghc, I expect the expression to be evaluated as the leading expression in an interactive interpreter session. Could we please tweak ghc like this to make it slightly more intuitive when these flags are used together? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9360> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression
by GHC 17 Oct '15

17 Oct '15

#10796: Illegal data constructor name: `fromList' ... When splicing a TH expression -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.3 Haskell | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- At the end is a log of my ghci session reproducing the issue. It is expected that the splice should succeed, but GHC complains "Illegal data constructor name: `fromList' ... When splicing a TH expression". Full definitions being used can be found at http://hackage.haskell.org/package/regex-tdfa-quasiquoter-0.2.0.0 . Briefly, this is the splice being used. {{{#!hs [e|patternToRegex $patternExp $compOptsExp $execOptsExp|] where patternExp = dataToExpQ (const Nothing) pattern compOptsExp = dataToExpQ (const Nothing) compOpts execOptsExp = dataToExpQ (const Nothing) execOpts }}} Data and Typeable instances are derived (using -XStandaloneDeriving -XDeriveDataTypeable) as orphan instances in the Internal module. The issue occurs when using bracket expressions (in POSIX regular expressions). There may be other cases but I have not uncovered them. {{{ > ghci GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. >>> :set -XQuasiQuotes >>> import Text.Regex.TDFA.QuasiQuoter >>> :t [re|;[a]|] Loading package transformers-0.3.0.0 ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package regex-base-0.93.2 ... linking ... done. Loading package text-1.2.0.3 ... linking ... done. Loading package parsec-3.1.9 ... linking ... done. Loading package regex-tdfa-1.2.0 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package regex-tdfa-quasiquoter-0.2.0.0 ... linking ... done. <interactive>:1:5: Illegal data constructor name: `fromList' When splicing a TH expression: Text.Regex.TDFA.TDFA.patternToRegex (GHC.Tuple.(,) (Text.Regex.TDFA.Pattern.POr ((GHC.Types.:) (Text.Regex.TDFA.Pattern.PConcat ((GHC.Types.:) (Text.Regex.TDFA.Pattern.PAny (Text.Regex.TDFA.Common.DoPa 1) (Text.Regex.TDFA.Pattern.PatternSet (Data.Maybe.Just (Data.Set.Base.fromList ((GHC.Types.:) 'a' GHC.Types.[]))) Data.Maybe.Nothing Data.Maybe.Nothing Data.Maybe.Nothing)) GHC.Types.[])) GHC.Types.[])) (GHC.Tuple.(,) 0 (Text.Regex.TDFA.Common.DoPa 1))) (Text.Regex.TDFA.Common.CompOption GHC.Types.True GHC.Types.True GHC.Types.True GHC.Types.True GHC.Types.False) (Text.Regex.TDFA.Common.ExecOption GHC.Types.True) >>> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10796> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10714: After implementing new installed package ID (hash of sdist), get rid of package keys
by GHC 15 Oct '15

15 Oct '15

#10714: After implementing new installed package ID (hash of sdist), get rid of package keys -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new 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: | -------------------------------------+------------------------------------- GHC tracking bug for https://github.com/haskell/cabal/issues/2745 Externally, GHC's flags do not have to change much; a user simply passes the installed package ID to the flag currently named `-this-package-key` (but perhaps we should rename this.) Internally, if we can assume that `PackageKey == InstalledPackageId`, we can do away with the `InstalledPackageId` map and get rid of the level of indirection between the bin-pkg-db (which records installed package IDs`) and GHC's guts (which record package keys). Blocked on Cabal not actually using ABI hashes to identify packages. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10714> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[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] #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] #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