June 2018 - ghc-tickets

[GHC] #15195: Merge -XPolyKinds with -XTypeInType
by GHC 26 Jun '18

26 Jun '18

#15195: Merge -XPolyKinds with -XTypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4748 | Wiki Page: -------------------------------------+------------------------------------- As described in [https://github.com/ghc-proposals/ghc- proposals/blob/master/proposals/0020-no-type-in-type.rst this accepted proposal]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15195> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15312: getChanContents exception behavior seems a bit odd
by GHC 26 Jun '18

26 Jun '18

#15312: getChanContents exception behavior seems a bit odd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.4.3 Libraries | 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: -------------------------------------+------------------------------------- I've been playing around with `Control.Concurrent.Chan` today. Something seems a bit off: {{{#!hs -- Bug.hs import Control.Concurrent (forkIO, yield) import Control.Concurrent.Chan import Data.List (elem) import Control.Exception import Control.Concurrent.MVar data Ex = Ex deriving Show instance Exception Ex main = do ch <- newChan sync1 <- newEmptyMVar sync2 <- newEmptyMVar forkIO $ do {writeList2Chan ch [1..3*10^6 :: Int]; putMVar sync1 ()} yield writeChan ch (-12) cont <- getChanContents ch tid <- forkIO $ do evaluate (last cont) putMVar sync2 () yield throwTo tid Ex print (elem (3*10^6) cont) takeMVar sync1 tryTakeMVar sync2 }}} When I run this single-threaded (`+RTS -N1`), it prints {{{ Bug: Ex Bug: Ex }}} One of the thunks in the lazy list gets overwritten by the (asynchronous) exception. This seems a bit surprising; is it the way it should be? Does `hGetContents` do this too? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15312> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14890: Make Linux slow validate green
by GHC 25 Jun '18

25 Jun '18

#14890: Make Linux slow validate green -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- Now since we will soon have a nightly slow validation, let's finally get it passing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14890> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #15205: Unnecessary equality superclass
by GHC 25 Jun '18

25 Jun '18

#15205: Unnecessary equality superclass -------------------------------------+------------------------------------- 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 {{{ {-# LANGUAGE MultiParamTypeClasses, GADTs, TypeOperators #-} module Foo where class (a ~ b) => C a b where op :: a -> a -> b f :: C a b => a -> b f x = op x x }}} If you compile this you'll end up with {{{ f = \ (@ a_a1dk) (@ b_a1dl) ($dC_a1dn :: C a_a1dk b_a1dl) (eta_B1 :: a_a1dk) -> case GHC.Types.heq_sel @ * @ * @ a_a1dk @ b_a1dl ((Foo.$p1C @ a_a1dk @ b_a1dl $dC_a1dn) `cast` (Data.Type.Equality.N:~[0] <*>_N <a_a1dk>_N <b_a1dl>_N :: (a_a1dk ~ b_a1dl) ~R# (a_a1dk ~~ b_a1dl))) of co_a1dw { __DEFAULT -> op @ a_a1dk @ b_a1dl $dC_a1dn eta_B1 eta_B1 } }}} What is that unused `heq_sel` doing? It happens during solving * We have `[G] a ~ b` * And, by superclasses we have `[G] a ~# b` * We use this to rewrite `a` to `b` in both givens and wanteds which is all fine, but we end up with {{{ f = \ (@ a_a1dk) (@ b_a1dl) ($dC_a1dn :: C a_a1dk b_a1dl) -> case GHC.Types.heq_sel @ * @ * @ a_a1dk @ b_a1dl (Data.Type.Equality.$p1~ @ * @ a_a1dk @ b_a1dl (Foo.$p1C @ a_a1dk @ b_a1dl $dC_a1dn)) of co_a1dw { __DEFAULT -> \ (x_axX :: a_a1dk) -> op @ a_a1dk @ b_a1dl (($dC_a1dn `cast` ((C co_a1dw <b_a1dl>_N)_R :: C a_a1dk b_a1dl ~R# C b_a1dl b_a1dl)) `cast` ((C (Sym co_a1dw) <b_a1dl>_N)_R :: C b_a1dl b_a1dl ~R# C a_a1dk b_a1dl)) x_axX x_axX } }}} Notice that `co_a1dw` is used. But we are just casting and casting back, so it ends up as Refl and `co_a1dw` is unused. Nothing is wrong here, but it seems inelegant * Can we discard that `heq_sel`? Perhaps we can declare that dictionary- valued terms are always treated strictly (#2439), so that `(heq_sel ...)` is guaranteed non-bottom, and we can discard the case. * Or maybe we can expand the given superclasses less aggressively, so that the equality isn't exposed until necessary. But see `Note [Eagerly expand given superclasses]` in `TcCanonical`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15205> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #1520: Use Linux's signalfd() instead of pipe() to deliver signals to the IO manager
by GHC 25 Jun '18

25 Jun '18

#1520: Use Linux's signalfd() instead of pipe() to deliver signals to the IO manager -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Runtime System | Version: 6.6.1 Resolution: wontfix | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The commit in comment:14 was really intended for #15290. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1520#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1520: Use Linux's signalfd() instead of pipe() to deliver signals to the IO manager
by GHC 25 Jun '18

25 Jun '18

#1520: Use Linux's signalfd() instead of pipe() to deliver signals to the IO manager -----------------------------------+--------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Runtime System | Version: 6.6.1 Resolution: wontfix | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------------+--------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"9fc40c733ba8822a04bd92883801b214dee099ca/ghc" 9fc40c73/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9fc40c733ba8822a04bd92883801b214dee099ca" Refactor the kind-checking of tyvar binders The refactoring here is driven by the ghastly mess described in comment:24 of Trac #1520. The overall goal is to simplify the kind-checking of typev-variable binders, and in particular to narrow the use of the "in-scope tyvar binder" stuff, which is needed only for associated types: see the new Note [Kind-checking tyvar binders for associated types] in TcHsType. Now * The "in-scope tyvar binder" stuff is done only in - kcLHsQTyVars, which is used for the LHsQTyVars of a data/newtype, or type family declaration. - tcFamTyPats, which is used for associated family instances; it now calls tcImplicitQTKBndrs, which in turn usese newFlexiKindedQTyVar * tcExpicitTKBndrs (which is used only for function signatures, data con signatures, pattern synonym signatures, and expression type signatures) now does not go via the "in-scope tyvar binder" stuff at all. While I'm still not happy with all this code, the code is generally simpler, and I think this is a useful step forward. It does cure the problem too. (It's hard to trigger the problem in vanilla Haskell code, because the renamer would normally use different names for nested binders, so I can't offer a test.) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1520#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15310: Derive Generic1 instances for types of kind (k -> *) -> * that include applications of the parameter
by GHC 25 Jun '18

25 Jun '18

#15310: Derive Generic1 instances for types of kind (k -> *) -> * that include applications of the parameter -------------------------------------+------------------------------------- Reporter: cedricshock | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: (Type checker) | Keywords: DeriveGeneric | Operating System: Unknown/Multiple Generic1 | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `Generic1` class is polykinded. The `DeriveGeneric` extension can derive `Generic1` instances for types of kind `k -> *` parameterized over a parameter with a kind other than `k ~ *`, but only if they don't apply the parameter to other types. It currently cannot derive an instance for {{{#!hs newtype Fix f = In (f (Fix f)) deriving (Generic1) }}} or for {{{#!hs data Child f = Child { ordinal :: Int, nickname :: f String } deriving (Generic1) }}} It's possible to represent these types generically, either with composition that can include occurrences of the parameter or with new types that represent applications of the parameter. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15310> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15299: GHCi :print produces variables that cause a panic
by GHC 25 Jun '18

25 Jun '18

#15299: GHCi :print produces variables that cause a panic --------------------------------------+------------------------------- Reporter: Omf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- Using ghci installed by Stack, I noted some strange behaviour from the :sprint and :print commands: {{{#!hs λ> xs = [1,2,3] λ> :sprint xs xs = _ λ> head xs 1 λ> :sprint xs xs = _ λ> :print xs xs = (_t1::Num a => [a]) λ> _t1 <interactive>:6:1: error: • No instance for (Num a) arising from a use of ‘_t1’ • In the expression: _t1 In an equation for ‘it’: it = _t1 λ> :t _t1 <interactive>:1:1: error: No instance for (Num a) arising from a use of ‘_t1’ λ> :info _t1 _t1 :: Num a => [a] -- Defined in ‘interactive:Ghci3’ λ> _t1 :: [Int] <interactive>:9:1: error:ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): No skolem info: a_a1rR Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcErrors.hs:2653:5 in ghc:TcErrors Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I don't really understand the error, or why even the :type command fails, but it appears to be related to the way numeric types are polymorphic until a specific type is forced. Note that the both the :sprint and :print commands don't seem to recognise that we've evaluated any of xs, just printing an underscore no matter what. The panic doesn't happen if I force a type when defining xs: {{{#!hs λ> xs = [1,2,3] :: [Int] λ> :sp xs xs = _ λ> head xs 1 λ> :sp xs xs = 1 : _ λ> :print xs xs = 1 : (_t2::[Int]) λ> _t2 [2,3] λ> :t _t2 _t2 :: [Int] λ> :in _t2 _t2 :: [Int] -- Defined in ‘interactive:Ghci6’ λ> _t2 :: [Integer] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15299> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15309: mkLHsOpTy is discarding API Annotations
by GHC 24 Jun '18

24 Jun '18

#15309: mkLHsOpTy is discarding API Annotations -------------------------------------+------------------------------------- Reporter: alanz | 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: Incorrect API Unknown/Multiple | annotation Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For {{{#!hs ft :: (->) a b }}} the `AnnRarrow` API annotation is discarded. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15309> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15292: ghc_ticker loops if permission denied on timerfd
by GHC 23 Jun '18

23 Jun '18

#15292: ghc_ticker loops if permission denied on timerfd ---------------------------------------+---------------------------------- Reporter: jon.fairbairn@… | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------------+---------------------------------- Using stack with lts-11.6 to compile a cgi programme, I got something that runs OK from the command line, but which goes into a busy loop when run from httpd. This is caused by selinux preventing read on the timer. Changing the selunix permissions solves the problems, but ghc-ticker ought to check whether the read succeeded and not try again if it fails. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15292> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4