- ghc-tickets - Haskell.org

[GHC] #15359: Quantified constraints do not work with equality constraints
by GHC 13 Sep '18

13 Sep '18

#15359: Quantified constraints do not work with equality constraints -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Feeling abusive toward GHC this morning, I tried this: {{{#!hs class C a b data Dict c where Dict :: c => Dict c foo :: (forall a b. C a b => a ~ b) => Dict (C a b) -> a -> b foo Dict x = x }}} I thought it wouldn't work, and I was right: {{{ • Class ‘~’ does not support user-specified instances • In the quantified constraint ‘forall (a :: k) (b :: k). C a b => a ~ b’ In the type signature: foo :: (forall a b. C a b => a ~ b) => Dict (C a b) -> a -> b }}} Good. But then I tried something more devious: {{{#!hs class C a b class a ~ b => D a b data Dict c where Dict :: c => Dict c foo :: (forall a b. C a b => D a b) => Dict (C a b) -> a -> b foo Dict x = x }}} This also fails, with ` Couldn't match expected type ‘b’ with actual type ‘a’`. I'm fine with the second case failing (because I think anything else would be very challenging), but the error message is unfortunate. According to the semantics of class constraints and quantified constraints, this case should be accepted. So if we reject it, we should have a good reason -- like we offer in the first case. Essentially, we need to explain that any logical entailment of an equality constraint simply doesn't hold in the presence of a quantified constraint. I neither know a good pithy way of explaining that to users nor how to detect when to do so. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15359> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #14025: Object file is put in wrong directory when any source has absolute path
by GHC 13 Sep '18

13 Sep '18

#14025: Object file is put in wrong directory when any source has absolute path -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) 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: -------------------------------------+------------------------------------- Files: `/tmp/e/A.hs`, `/tmp/e/dep.c`. Current dir: `/tmp/e`. `ghc -odir /tmp/xyzzy A.hs dep.c`: works as expected, puts `dep.o` in `/tmp/xyzzy`. But try to prefix either `A.hs` or `dep.c` (or both) with `/tmp/e/`, and suddenly `dep.o` is put in `/tmp/e`, not in `/tmp/xyzzy`. Couldn't check with 8.2.1 yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14025> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #614: Rewrite the I/O library.
by GHC 12 Sep '18

12 Sep '18

#614: Rewrite the I/O library. ----------------------------------+-------------------- Reporter: simonmar | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: None Resolution: None | Keywords: Type of failure: None/Unknown | ----------------------------------+-------------------- Changes (by Ben Gamari <ben@…>): * failure: => None/Unknown Comment: In [changeset:"900c47f88784b91517c00be3e1087322e62f698e/ghc" 900c47f8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="900c47f88784b91517c00be3e1087322e62f698e" rts/Printer.c: always define the findPtr symbol It was previously only defined (and therefore shipped) when DEBUG is defined. This patch defines it regardless of DEBUG. This will help fix hadrian on OS X [1]. [1]: https://github.com/snowleopard/hadrian/issues/614 Test Plan: The error from hadrian#614 is gone Reviewers: bgamari, erikd, simonmar Reviewed By: simonmar Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5138 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/614#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15631: Lost opportunity to eliminate seq
by GHC 12 Sep '18

12 Sep '18

#15631: Lost opportunity to eliminate seq -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- Consider this: {{{ f xs = let ys = reverse xs in ys `seq` length xs + length (reverse (case ys of { a:as -> as; [] -> [] })) }}} We end up with this {{{ Foo.$wf = \ (@ a_s4a0) (w_s4a1 :: [a_s4a0]) -> (1) case GHC.List.reverse1 @ a_s4a0 w_s4a1 (GHC.Types.[] @ a_s4a0) of ys_ap9 { __DEFAULT -> case GHC.List.$wlenAcc @ a_s4a0 w_s4a1 0# of ww2_a49t { __DEFAULT -> (2) case ys_ap9 of { [] -> case Foo.f1 @ a_s4a0 of { GHC.Types.I# v1_B2 -> GHC.Prim.+# ww2_a49t v1_B2 }; : a1_aK8 as_aK9 -> case GHC.List.$wlenAcc @ a_s4a0 (GHC.List.reverse1 @ a_s4a0 as_aK9 (GHC.Types.[] @ a_s4a0)) 0# of ww1_X49V { __DEFAULT -> GHC.Prim.+# ww2_a49t ww1_X49V } } } } }}} The case expression (1) is the `seq` on ys. The case marked (2) is the case analysis in the argument of the second `reverse`. But that first `seq` is redundant! We could equally well say {{{ Foo.$wf = \ (@ a_s4a0) (w_s4a1 :: [a_s4a0]) -> case GHC.List.$wlenAcc @ a_s4a0 w_s4a1 0# of ww2_a49t { __DEFAULT -> (2) case GHC.List.reverse1 @ a_s4a0 w_s4a1 (GHC.Types.[] @ a_s4a0) of { [] -> case Foo.f1 @ a_s4a0 of { GHC.Types.I# v1_B2 -> GHC.Prim.+# ww2_a49t v1_B2 }; : a1_aK8 as_aK9 -> case GHC.List.$wlenAcc @ a_s4a0 (GHC.List.reverse1 @ a_s4a0 as_aK9 (GHC.Types.[] @ a_s4a0)) 0# of ww1_X49V { __DEFAULT -> GHC.Prim.+# ww2_a49t ww1_X49V } } } } }}} That's better because we generate code for only two evals rather than three. The general pattern is {{{ case <scrut> of b { DEFAULT -> <body> } ==> let b = <scrut> in <body> }}} where the case binder `b` is used strictly in `<body>`. In this case it's safe to switch to a `let` (marked as strict) which can now be inlined or floated in a way that `case` expressions cannot. We already do this transformation, here in `Simplify.rebuildCase`: {{{ rebuildCase env scrut case_bndr alts@[(_, bndrs, rhs)] cont ... | all_dead_bndrs , if isUnliftedType (idType case_bndr) then exprOkForSpeculation scrut else exprIsHNF scrut || scrut_is_demanded_var scrut = ...turn case into let... }}} The key bit (for this situation) is `scrut_is_demanded_var`. '''But it only fires if `<scrut>` is a variable'''. I see no reason for this restriction. I think it's sound regardless. Yes, if we decide to inline the binding `b = <scrut>` we might change which exception appears; but that is within the semantics of exceptions; and it's still true if `<scrut>` is a variable. So I think we can safely replace `scrut_is_demand_var` with just `case_bndr_is_demanded`, independent of what `scrut` looks like. I dug back into ghc history to see how the current code came about, bu it had a long evolution and I didn't find any reason for sticking to a variable here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15631> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15628: Higher-rank kinds
by GHC 12 Sep '18

12 Sep '18

#15628: Higher-rank kinds -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 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: -------------------------------------+------------------------------------- Taken from [https://github.com/ekmett/eq/blob/master/src/Data/Eq/Type/Hetero.hs#L73 Data.Eq.Type.Hetero]. `(:==)` (called `HEq` to avoid unnecessary extensions) fails if you add a `Proxy x ->` argument. {{{#!hs {-# Language RankNTypes, KindSignatures, PolyKinds, GADTs, DataKinds #-} import Data.Kind import Data.Proxy newtype HEq :: forall j. j -> forall k. k -> Type where HEq :: (forall (x::forall xx. xx -> Type). Proxy x -> x a -> x b) -> HEq a b }}} {{{ $ ~/code/latestghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci 398.hs GHCi, version 8.7.20180828: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 398.hs, interpreted ) 398.hs:7:2: error: • A newtype constructor cannot have existential type variables HEq :: forall j k xx (a :: j) (b :: k). (forall (x :: forall xx1. xx1 -> *). Proxy x -> x a -> x b) -> HEq a b • In the definition of data constructor ‘HEq’ In the newtype declaration for ‘HEq’ | 7 | HEq | ^^^... Failed, no modules loaded. Prelude> }}} It compiles fine without `Proxy x ->`. Now my question is what existential type variable does `HEq` have, `-fprint-explicit-kinds` shows that `Proxy` is actually being instantiated at `(xx -> Type)` and not `(forall xx. xx -> Type)` {{{ 398.hs:10:2: error: • A newtype constructor cannot have existential type variables HEq :: forall j k xx (a :: j) (b :: k). (forall (x :: forall xx1. xx1 -> *). Proxy (xx -> *) (x xx) -> x j a -> x k b) -> HEq j a k b • In the definition of data constructor ‘HEq’ In the newtype declaration for ‘HEq’ | 10 | HEq | ^^^... }}} so I suppose my question is, can we instantiate `Proxy` at a higher-rank kind? (#12045: `Proxy @FOO`) {{{ >> type FOO = (forall xx. xx -> Type) >> :kind (Proxy :: FOO -> Type) <interactive>:1:2: error: • Expected kind ‘FOO -> *’, but ‘Proxy’ has kind ‘k0 -> *’ • In the type ‘(Proxy :: FOO -> Type)’ }}} It is possible to create a bespoke `Proxy` {{{#!hs type FOO = (forall x. x -> Type) data BespokeProxy :: FOO -> Type where BespokeProxy :: forall (c :: FOO). BespokeProxy c newtype HEq :: forall j. j -> forall k. k -> Type where HEq :: (forall (x::forall xx. xx -> Type). BespokeProxy x -> x a -> x b) -> HEq a b }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15628> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15619: List comprehension seems to prevent some rewrite rules to fire
by GHC 11 Sep '18

11 Sep '18

#15619: List comprehension seems to prevent some rewrite rules to fire -------------------------------------+------------------------------------- Reporter: nobrakal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, Consider {{{#!hs module Test (problem, noProblem) where data Relation = Relation Int vertex :: Int -> Relation vertex = Relation {-# NOINLINE vertex #-} star :: Int -> [Int] -> Relation star x [] = vertex x star x xs = vertex x {-# INLINE star #-} transpose :: Relation -> Relation transpose (Relation e) = Relation (-e) {-# NOINLINE transpose #-} {-# RULES "transpose/vertex" forall x. transpose (vertex x) = vertex x #-} -- The "transpose/vertex" rule does not fire here problem :: Relation problem = transpose $ star 0 [1..2] -- The "transpose/vertex" rule does fire here noProblem :: Relation noProblem = transpose $ star 0 [1,2] }}} `problem` and `noProblem` seems equivalents, but in the first the rewrite rule does not fire. * Commenting `noProblem` and compiling with "-ddump-rule-firings" gives: {{{ [1 of 1] Compiling Test ( Test.hs, Test.o ) Rule fired: Class op negate (BUILTIN) Rule fired: Class op enumFromTo (BUILTIN) Rule fired: eftIntList (GHC.Enum) }}} * Commenting `problem` and compiling with "-ddump-rule-firings" gives: {{{ [1 of 1] Compiling Test ( Test.hs, Test.o ) Rule fired: Class op negate (BUILTIN) Rule fired: transpose/vertex (Test) }}} It is a very "borderline" example (refined from a more complex one): * changing the `data` to a `newtype` solves the problem * removing the dumb pattern-match on the list in `star` also solves the problem I suspect the list comprehension to be the problem, but I am not sure at all (I am not sure if the whole thing is a real bug indeed). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15619> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15626: Optimise wakeups for STM
by GHC 11 Sep '18

11 Sep '18

#15626: Optimise wakeups for STM -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4961 | Wiki Page: -------------------------------------+------------------------------------- As discovered while debugging #15544, the previous attempt at optimising STM wakeups (Phab:D4961, merged as 502640c90c3d0fbb6c46257be14fdc7e3c694c6c) broke other things (see comment 17) and we're going to revert it. This is the tracking ticket for this issue. To summarize the problem: when a thread from capability 2 is in wait list of a TVar and we update the TVar in capability 1 we send a wakeup message to capability 2. If before capability 2 actually wake ups the thread capability 1 updates the TVar again we send a message again, causing redundant wakeup message sending. Ideally we should somehow mark the TSO as "awoken" and not send wakeup messages more than once. Phab:D4961 did exactly this, but in a wrong way (updated a field of TSO that shouldn't have been updated). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15626> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11197: Overeager deferred type errors
by GHC 11 Sep '18

11 Sep '18

#11197: Overeager deferred type errors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- With `TypeInType`, the solver now works in terms of unlifted equality. The only place this matters is in deferred type errors, which now are more eager than they were before. For example: {{{ {-# OPTIONS_GHC -fdefer-type-errors #-} module Main where main = do putStrLn "Hi there." putStrLn True }}} This used to print {{{ Hi there. Defer: Defer.hs:7:12: error: ... }}} Now it prints {{{ Defer: Defer.hs:7:12: error: ... }}} No more `Hi there.`. Thinking about Core, this change should be expected. GHC puts all evidence bindings for `main` at the top, and with unlifted equality in the solver, these bindings now contain `case typeError ... of ...`, which forces the type error eagerly. Previously, there was a lazy binding for a lifted equality witness, unpacked only at the last moment by magic in the desugarer, thus the lazier warning. Simon has proposed customizing the !FloatIn pass to deal with this scenario. I do believe this would work nicely, but I have not yet implemented it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11197> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #15624: defer-type-errors and equality constraints
by GHC 11 Sep '18

11 Sep '18

#15624: defer-type-errors and equality constraints -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 (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: -------------------------------------+------------------------------------- Consider {{{ {-# OPTIONS_GHC -fdefer-type-errors #-} x = const True ('a' + 'a') y = const True (not 'a') }}} Currently `x` is True, but `y` is undefined. I think it would make sense for both to be True. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15624> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #3427: control what sort of entity a deprecated pragma applies to
by GHC 11 Sep '18

11 Sep '18

#3427: control what sort of entity a deprecated pragma applies to -------------------------------------+------------------------------------- Reporter: igloo | Owner: nineonine Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: deprecate | warning, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5126 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nineonine): Submitted a proposal: https://github.com/ghc-proposals/ghc- proposals/pull/167 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3427#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0