February 2018 - ghc-tickets

[GHC] #13838: -Wdeferred-type-errors; ghc: panic!; VoidRep; ((() -> ()) :: *) ~# (IO Any :: *)
by GHC 30 May '18

30 May '18

#13838: -Wdeferred-type-errors; ghc: panic!; VoidRep; ((() -> ()) :: *) ~# (IO Any :: *) -------------------------------------+------------------------------------- Reporter: harry | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- My Compiler told me to report this so here you go: {{{ [1 of 1] Compiling Main ( ghc_bug.hs, interpreted ) ghc_bug.hs:3:1: warning: [-Wdeferred-type-errors] * Couldn't match expected type `IO t0' with actual type `() -> ()' * Probable cause: `main' is applied to too few arguments In the expression: main When checking the type of the IO action `main' ghc_bug.hs:3:8: warning: [-Wdeferred-type-errors] * Couldn't match expected type `() -> () -> ()' with actual type `()' * The function `()' is applied to one argument, but its type `()' has none In the expression: () () In an equation for `main': main = () () ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): corePrepPgm [False] cobox_r1a0 = typeError @ 'VoidRep @ ((() -> ()) :: *) ~# (IO Any :: *) "ghc_bug.hs:3:1: error:\n\ \ * Couldn't match expected type `IO t0' with actual type `() -> ()'\n\ \ * Probable cause: `main' is applied to too few arguments\n\ \ In the expression: main\n\ \ When checking the type of the IO action `main'\n\ \(deferred type error)"# Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} {{{#!hs main :: () -> () main = () () }}} which that in "ghc_bug.hs" "ghc ghc_bug.hs -fdefer-type-errors -dcore-lint -v" gives me the following: {{{ Glasgow Haskell Compiler, Version 8.0.1, stage 2 booted by GHC version 7.10.3 Using binary package database: /usr/lib/ghc-8.0.1/package.conf.d/package.cache Using binary package database: /home/harry/.ghc/x86_64-linux-8.0.1/package.conf.d/package.cache loading package database /usr/lib/ghc-8.0.1/package.conf.d loading package database /home/harry/.ghc/x86_64-linux-8.0.1/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.11.0.0 wired-in package ghc mapped to ghc-8.0.1 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: loading package database /usr/lib/ghc-8.0.1/package.conf.d loading package database /home/harry/.ghc/x86_64-linux-8.0.1/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.0.0 wired-in package rts mapped to rts-1.0 wired-in package template-haskell mapped to template-haskell-2.11.0.0 wired-in package ghc mapped to ghc-8.0.1 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *ghc_bug.hs !!! Chasing dependencies: finished in 0.42 milliseconds, allocated 0.211 megabytes Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = ****-**-** **:**:**.********** *** ms_mod = Main, ms_textual_imps = [(Nothing, Prelude)] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file ghc_bug.hs *** Checking old interface for Main: [1 of 1] Compiling Main ( ghc_bug.hs, ghc_bug.o ) *** Parser [Main]: !!! Parser [Main]: finished in 0.14 milliseconds, allocated 0.089 megabytes *** Renamer/typechecker [Main]: !!! Renamer/typechecker [Main]: finished in 28.70 milliseconds, allocated 14.769 megabytes *** Desugar [Main]: Result size of Desugar (after optimization) = {terms: 19, types: 52, coercions: 4} *** Core Linted result of Desugar (after optimization): *** Core Lint errors : in result of Desugar (after optimization) *** <no location info>: warning: [RHS of cobox_aOD :: ((() -> ()) :: *) ~# (IO Any :: *)] The type of this binder is primitive: cobox_aOD Binder's type: ((() -> ()) :: *) ~# (IO Any :: *) *** Offending Program *** main :: () -> () [LclIdX, Str=DmdType] main = case typeError @ 'VoidRep @ (() :: *) ~# ((() -> () -> ()) :: *) "ghc_bug.hs:2:8: error:\n\ \ * Couldn't match expected type `() -> () -> ()'\n\ \ with actual type `()'\n\ \ * The function `()' is applied to one argument,\n\ \ but its type `()' has none\n\ \ In the expression: () ()\n\ \ In an equation for `main': main = () ()\n\ \(deferred type error)"# of cobox_aOE { __DEFAULT -> (() `cast` (Sub cobox_aOE :: (() :: *) ~R# ((() -> () -> ()) :: *))) () } $trModule :: Module [LclIdX, Str=DmdType] $trModule = Module (TrNameS "main"#) (TrNameS "Main"#) cobox_aOD :: ((() -> ()) :: *) ~# (IO Any :: *) [LclId[CoVarId], Str=DmdType] cobox_aOD = typeError @ 'VoidRep @ ((() -> ()) :: *) ~# (IO Any :: *) "ghc_bug.hs:2:1: error:\n\ \ * Couldn't match expected type `IO t0' with actual type `() -> ()'\n\ \ * Probable cause: `main' is applied to too few arguments\n\ \ In the expression: main\n\ \ When checking the type of the IO action `main'\n\ \(deferred type error)"# main :: IO Any [LclIdX, Str=DmdType] main = runMainIO @ Any (main `cast` (Sub cobox_aOD :: ((() -> ()) :: *) ~R# (IO Any :: *))) *** End of Offense *** <no location info>: error: Compilation had errors *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: }}} and gcc version is: gcc version 7.1.1 20170516 (GCC) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13838> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14789: GHCi fails to garbage collect declaration `l = length [1..10^8]` entered at prompt
by GHC 30 May '18

30 May '18

#14789: GHCi fails to garbage collect declaration `l = length [1..10^8]` entered at prompt -------------------------------------+------------------------------------- Reporter: kabuhr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 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: -------------------------------------+------------------------------------- This was recently reported on Stack Overflow (https://stackoverflow.com/questions/48723119/binding-len-length-xs-and- then-calculating-len-causes-ghc-to-consume-lots). With GHC 8.2.2, assigning the length of a large list as a top-level declaration at the GHCi prompt and evaluating it: {{{ Prelude> l = length [1..10^8] Prelude> l 10000000 Prelude> }}} allocates about 7 gigs of memory before displaying a result, and then memory continues to grow over the next few seconds (at the idle GHCi prompt) until 10 gigs of memory has been allocated. None of it is freed until the interpreter session ends. In contrast, directly evaluating the expression or assigning it with a let-statement does **not** exhibit this behavior: {{{ Prelude> length [1..10^8] 10000000 Prelude> let l = length [1..10^8] Prelude> l 10000000 Prelude> }}} Also, loading the top-level declaration from a file and then evaluating it at the prompt does **not** exhibit the problem. I took a look at Ticket [ticket: 14336] and applied the `-fno-it` patch referenced there. This slightly changed the pattern of memory usage: it grew to about 4 gigs before displaying the result, but then continued to grow for several seconds at the GHCi prompt before landing at about 10 gigs. I verified that the bug still exists on the current "master" branch (though I didn't check the "ghc-8.4" branch). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14789> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9438: panic: loading archives not supported
by GHC 29 May '18

29 May '18

#9438: panic: loading archives not supported ----------------------------------+---------------------------------- Reporter: egl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+---------------------------------- Running {{{ ghci -L/opt/local/lib -latlas }}} eventually leads to {{{ Loading object (static archive) /opt/local/lib/libatlas.a ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Loading archives not supported Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This looks similar to 8164 and 4828, which are marked closed. Mac OSX 10.9.4 Xcode 5.1.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9438> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14032: Can't splice TH quote with infix declaration for name in two different namespaces
by GHC 29 May '18

29 May '18

#14032: Can't splice TH quote with infix declaration for name in two different namespaces -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | 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: -------------------------------------+------------------------------------- Spun off from #13799 (and https://ghc.haskell.org/trac/ghc/ticket/13054#comment:2) This code compiles: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeOperators #-} infix 5 :*: data a :*: b = a :*: b }}} But this code does not: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeOperators #-} $([d| infix 5 :*: data a :*: b = a :*: b |]) }}} {{{ $ /opt/ghc/8.2.1/bin/ghc -ddump-splices Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Bug.hs:(4,3)-(6,6): Splicing declarations [d| infix 5 :*:_anM, :*:_anL data a_anN :*:_anL b_anO = a_anN :*:_anM b_anO |] ======> infix 5 :*:_a3IL infix 5 :*:_a3IK data (:*:_a3IK) a_a3IM b_a3IN = a_a3IM :*:_a3IL b_a3IN Bug.hs:4:3: error: Multiple fixity declarations for ‘:*:_a3IL’ also at Bug.hs:(4,3)-(6,6) | 4 | $([d| infix 5 :*: | ^^^^^^^^^^^^^^^... }}} Inspecting the `-ddump-splices` output reveals why: when `infix 5 :*:` is renamed, because `:*:` refers to two different names in both the value and type namespaces, it actually gets renamed to `infix 5 :*:_anM, :*:_anL`, where `:*:_anM` and `:*:_anL` are the same name with different uniques. Normally, this isn't a problem, since feeding `infix 5 :*:_anM, :*:_anL` to the typechecker works fine. However, when it's spliced in via Template Haskell, it gets fed back into the renamer, where it believes that `:*:_anM` and `:*:_anL` are duplicate names, causing the error. Really, this is just a symptom of the fact that infix declarations are insufficiently powerful to encode information for identical names in different namespaces. But until GHC gains this ability, we need to find some workaround for this problem. My hunch is that we'll need to give GHC the power to recognize these sorts of duplicate fixity declarations in `Convert` and only emit one actual fixity declaration per set of duplicates. (Disclaimer: I haven't worked out all the fiddly details yet.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14032> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13126: Support for hexadecimal floats
by GHC 29 May '18

29 May '18

#13126: Support for hexadecimal floats -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Currently, Haskell only allows writing floating-point numbers in the decimal format. Unfortunately, writing floats in decimal/scientific format is not always the best option, due to loss of precision. As an alternative, there's the so called "hexadecimal floating point" format, described in p57-58 of: http://www.open- std.org/jtc1/sc22/wg14/www/docs/n1256.pdf The format is rather simple, unambiguous, and relatively easy to implement. And it's been around for about 10 years by now. It would be nice if the Haskell standard was changed to include such literals. But in the meantime, perhaps GHC can support such literals via a pragma, such as `LANGUAGE HexadecimalFloats` or similar. A corresponding pretty printer (similar to C's %a specifier) is also needed; which should go into the standard `Numerics` module. Such a function can be called `showHFloat` to accompany the similarly named functions for rendering float values. A reference implementation can be given by template-Haskell splicing, and indeed the hackage package FloatingHex (http://hackage.haskell.org/package/FloatingHex) provides both a quasi- quoter for such literals, and the pretty printer `showHFloat.` Unfortunately, this solution is less than satisfactory as it relies on the rather heavy mechanism for quasi-quotes, requires an extra library dependency, a pragma (`QuasiQuotes`), and the import and dependency of a hackage package, which sounds a lot for just being able to write floats precisely! Furthermore, Tempate Haskell has an issue with the storage of floats (https://ghc.haskell.org/trac/ghc/ticket/13124) which makes the library solution less than ideal in overflow cases. (Long story short: Template- Haskell stores floating literals as rationals, and thus has no reliable way of representing floats such as NaN, Infinity, and especially negative- zero.) Numeric programming is important, especially in this new era of HPC, and many-core architectures tuned for crunching floating-point data seamlessly. While this is admittedly a minor step, I think it'll be a positive addition to GHC from a maturity perspective, and that of matching/leading other languages out there. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13126> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14602: Implement the pattern synonym construction function signatures proposal
by GHC 29 May '18

29 May '18

#14602: Implement the pattern synonym construction function signatures proposal -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 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: -------------------------------------+------------------------------------- [https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0005 -bidir-constr-sigs.rst The pattern synonym construction function signatures proposal] has been accepted and should be implemented. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14602> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10843: Allow do blocks without dollar signs as arguments
by GHC 29 May '18

29 May '18

#10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I would like the following to be valid Haskell code: {{{#!hs main = when True do putStrLn "Hello!" }}} Instead of requiring a dollar sign before the "do". This would parse as {{{#!hs main = when True (do putStrLn "Hello!") }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10843> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 48

[GHC] #9793: Some as-patterns could be accepted in pattern synonyms
by GHC 29 May '18

29 May '18

#9793: Some as-patterns could be accepted in pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: pattern synonyms | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Easy (less than 1 | None/Unknown hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Currently all as-patterns are rejected in pattern synonym definitions, to avoid situations like {{{ pattern P x y <- x@(y:_) }}} since there's no valid reason to be able to then write something like {{{ f [True] False = ... }}} this would just lead to confusion. However, I think we could accept as-patterns where the body of the as- pattern doesn't contain any variable bindings that are accessible via the pattern synonym. In other words, this should be OK: {{{ pattern P x <- x@(y:_) }}} since it's exactly equivalent to {{{ pattern P x <- x@(_:_) }}} which I don't think is as confusing as the other example. I haven't really made up my mind yet if these should be bidirectional; but they certainly could be, by just ignoring the body of the as-pattern in the wrapper; so the following two would be equivalent: {{{ pattern P1 x = [x@(y:_)] pattern P2 x <- [x@(y:_)] where P2 x = [x] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9793> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #12540: RFC: Allow not quantifying every top-level quantifiee
by GHC 27 May '18

27 May '18

#12540: RFC: Allow not quantifying every top-level quantifiee -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Minor nuisance, does this happen to anyone else? Currently Haskell has an all-nothing policy on quantified type variables, either you quantify none or all (fine, let's ignore non-prenex quantification `foo :: a -> forall b. b -> a`). Can we have a top-level quantification of only a subset of the free variables? Say I'm working on a function {{{#!hs reflected :: forall s m a. (Applicative m, Reifies s a) => TaggedT s m a }}} and I need to make ''s'' a scoped type variable, I always accidentally write {{{#!hs reflected :: forall s. (Applicative m, Reifies s a) => TaggedT s m a reflected = TagT . pure . reflect $ (Proxy :: Proxy s) }}} This causes GHC to complain that the other types — ''m'', ''a'' — are not in scope so and I have to add the remaining quantifiees I don't really care about (may have long names as well). It could be worse (''dramatization'') {{{#!hs ipartsOf :: forall i p f s t a. (Indexable [i] p, Functor f) => Traversing (Indexed i) f s t a a -> Over p f s t [a] [a] ipartsOf l = conjoined (\f s -> let b = inline l sell s in outs b <$> f (wins b)) (\f s -> let b = inline l sell s; (is, as) = unzip (pins b) in outs b <$> indexed f (is :: [i]) as) appendAssocAxiom :: forall p q r as bs cs. p as -> q bs -> r cs -> Dict ((as ++ (bs ++ cs)) ~ ((as ++ bs) ++ cs)) appendAssocAxiom _ _ _ = unsafeCoerce (Dict :: Dict (as ~ as)) }}} It would be nice to be nice to only have to specify the type one is interested in: {{{#!hs ipartsOf :: forall i. (Indexable [i] p, Functor f) => Traversing (Indexed i) f s t a a -> Over p f s t [a] [a] appendAssocAxiom :: forall as. p as -> q bs -> r cs -> Dict ((as ++ (bs ++ cs)) ~ ((as ++ bs) ++ cs)) }}} and have the others chosen in some way. This is not just useful for writing, but it makes it easier to read: If I see a type `forall i p f s t a. ...` any of them may appear in the function body, if I see a type `forall i. ...` I know only one is. Thoughts? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12540> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9427: Do finer-grained dependency analysis to infer more general kinds on type/class declarations
by GHC 27 May '18

27 May '18

#9427: Do finer-grained dependency analysis to infer more general kinds on type/class declarations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | 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: -------------------------------------+------------------------------------- In the resolution to #9200, as detailed [wiki:GhcKinds/KindInference#Apossiblevariation here], we identified an area for improvement. This improvement was not implemented in the fix for #9200. This ticket will track just this improvement. (In brief: we can do better dependency analysis on mutually recursive type/class declarations to allow more kinds to generalize earlier. This would lessen the burden on programmers to put in kind annotations. See the wiki page.) A solid but unfinished attempt is [https://github.com/goldfirere/ghc/tree /re-sort-non-cusk-decls here]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9427> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4