September 2018 - ghc-tickets

[GHC] #14391: Make the simplifier independent of the typechecker
by GHC 05 Oct '18

05 Oct '18

#14391: Make the simplifier independent of the typechecker -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I noticed that the simplifier module depends on all of the type checker, and HsSyn stuff, and renamer stuff, which I found strange. After a little investigation, it seems that the simplifier depends on CoreMonad, and that pulls some very few type-checker related things: 1. {{{ import TcRnMonad ( initTcForLookup ) import {-# SOURCE #-} TcSplice ( lookupThName_maybe ) }}} for {{{ thNameToGhcName :: TH.Name -> CoreM (Maybe Name) thNameToGhcName th_name = do hsc_env <- getHscEnv liftIO $ initTcForLookup hsc_env (lookupThName_maybe th_name) }}} which is not even used in GHC, but only in GHC Plugins, so this could probably be moved to a separate module pulled in by GhcPlugins.hs 2. {{{ import TcEnv ( lookupGlobal ) }}} for {{{ instance MonadThings CoreM where lookupThing name = do { hsc_env <- getHscEnv ; liftIO $ lookupGlobal hsc_env name } }}} This might be a bit harder to disentangle. But if successful, it would probably make building GHC in parallel quite a bit faster. And it just seems strange to me that the Core-to-Core code should depend on the type checker… Simon says: > Both of these code paths go through initTcForLookup which is massive overkill, as the comment with `TcEnv.lookupGlobal` says. There's clearly a ToDo here to strip off the redundant stuff and do a minimal lookup. I am optimistically marking this as `newcomer` because it is a refactoring task, and a good way of learning a bit about various pieces, with a reasonably clear notion of “success”. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14391> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 44

[GHC] #15383: T3171 doesn't terminate with Interrupted message on Darwin
by GHC 04 Oct '18

04 Oct '18

#15383: T3171 doesn't terminate with Interrupted message on Darwin -------------------------------------+------------------------------------- Reporter: bgamari | 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: -------------------------------------+------------------------------------- I am seeing `T3171` fail with incorrect stderr output on Darwin (e.g. https://circleci.com/gh/ghc/ghc/7106) {{{ Actual stdout output differs from expected: --- ./ghci/should_run/T3171.run/T3171.stdout.normalised 2018-07-14 21:24:25.000000000 -0700 +++ ./ghci/should_run/T3171.run/T3171.run.stdout.normalised 2018-07-14 21:24:25.000000000 -0700 @@ -1 +0,0 @@ -Interrupted. *** unexpected failure for T3171(normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15383> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15235: GHCi's claim of infixr 0 (->) is a lie
by GHC 04 Oct '18

04 Oct '18

#15235: GHCi's claim of infixr 0 (->) is a lie -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: -------------------------------------+------------------------------------- Currently, if you query the `:info` for `(->)` in GHCi, it will give you: {{{ $ ghci GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci λ> :i (->) data (->) (a :: TYPE q) (b :: TYPE r) -- Defined in ‘GHC.Prim’ infixr 0 `(->)` <instances elided> }}} This fixity information appears to be plain wrong, as the following program demonstrates: {{{#!hs {-# LANGUAGE TypeOperators #-} module Bug where import Data.Type.Equality type (~>) = (->) infixr 0 ~> f :: (a ~> b -> c) :~: (a ~> (b -> c)) f = Refl }}} Since `(~>)` and `(->)` are both `infixr 0`, I would expect `a ~> b -> c` to associate as `a ~> (b -> c)`, like the type signature for `f` wants to prove. However, GHC believes otherwise: {{{ $ ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:10:5: error: • Occurs check: cannot construct the infinite type: a ~ a ~> b Expected type: ((a ~> b) -> c) :~: (a ~> (b -> c)) Actual type: ((a ~> b) -> c) :~: ((a ~> b) -> c) • In the expression: Refl In an equation for ‘f’: f = Refl • Relevant bindings include f :: ((a ~> b) -> c) :~: (a ~> (b -> c)) (bound at Bug.hs:10:1) | 10 | f = Refl | ^^^^ }}} Reading the error message above, it appears that GHC gives `(->)` an even //lower// precedence than 0, since it associates `a ~> b -> c` as `(a ~> b) -> c`. I'm not sure how to reconcile these two facts. There are at least a couple of options I can think of: 1. Claim `(->)` has a negative fixity. 2. Try to change GHC so that `(->)` really is `infixr 0`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15235> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8708: Kind annotation in tuple not parsed
by GHC 04 Oct '18

04 Oct '18

#8708: Kind annotation in tuple not parsed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Consider this: {{{ {-# LANGUAGE KindSignatures #-} foo :: (Int, Int :: *) foo = undefined }}} HEAD reports {{{ /Users/rae/temp/Bug.hs:5:18: parse error on input ‛::’ }}} Changing the line to {{{ foo :: (Int, (Int :: *)) }}} fixes the problem. Note the extra parentheses. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8708> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11622: Annotating types in type familiy equations without parentheses
by GHC 04 Oct '18

04 Oct '18

#11622: Annotating types in type familiy equations without parentheses -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- When annotating types in right-hand side of type family equations parentheses are required: {{{#!hs type family F a where F _ = (Int :: Type) }}} instead of {{{#!hs type family F a where F _ = Int :: Type }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11622> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15233: You can always set fixity of (:), with no effect
by GHC 04 Oct '18

04 Oct '18

#15233: You can always set fixity of (:), with no effect -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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): | Wiki Page: -------------------------------------+------------------------------------- This works in a normal file {{{#!hs infixl 5 : }}} or in ghci {{{ $ ghci GHCi, version 8.5.20180314: http://www.haskell.org/ghc/ :? for help Prelude> infixr 5 : Prelude> }}} and has no effect -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15233> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15167: DerivClause list is not populated for (TyConI (DataD ...))
by GHC 04 Oct '18

04 Oct '18

#15167: DerivClause list is not populated for (TyConI (DataD ...)) -------------------------------------+------------------------------------- Reporter: 0xd34df00d | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template | Version: 8.4.2 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: -------------------------------------+------------------------------------- {{{#!haskell % cat Test.hs {-# LANGUAGE LambdaCase #-} module Test where import Language.Haskell.TH test :: Name -> Q [Dec] test name = reify name >>= \case TyConI dec -> do runIO $ print dec pure [] _ -> pure [] % cat Run.hs {-# LANGUAGE TemplateHaskell #-} import Test data Foo = Foo deriving (Eq, Ord, Show) test ''Foo % ghc Run.hs [2 of 2] Compiling Main ( Run.hs, Run.o ) DataD [] Main.Foo [] Nothing [NormalC Main.Foo []] [] }}} One might expect the `DataD` to mention `Eq, Ord, Show` in the `DerivClause` list, but it doesn't. This behavior manifests with every ghc version I tried: 8.0.2, 8.2.2, 8.4.2. I also asked a question whether it's intended behaviour on #haskell, and I've been advised to open a bug report, so here it is. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15167> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11251: isInstance does not work on Typeable with base-4.8 anymore
by GHC 04 Oct '18

04 Oct '18

#11251: isInstance does not work on Typeable with base-4.8 anymore -------------------------------------+------------------------------------- Reporter: songzh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 libraries/base | Keywords: Typeable, | Operating System: Unknown/Multiple isInstance | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs > :set -XTemplateHaskell > :m +Data.Tyepable > :m +Language.Haskell.TH --- With GHC 7.8 or earlier versions of GHC (I only tried with GHC 7.6, but my friends tried on 7.8 and earlier versoin) > $(isInstance ''Typeable [ConT ''Char] >>= stringE.show) "True" --- With GHC 7.10.1 > $(isInstance ''Typeable [ConT ''Char] >>= stringE.show) "False" }}} I have noticed that standalone derivings of Typeable instances in Data.Typeable are disappared magically in base-4.8 of GHC 7.10,also one cannot query the instances of it by using `:i Typeable` in GHCi, however, obviously, I can use `typeOf` function in base-4.8 to get the TypeRep of Char. The problem is that `isInstance` in template-haskell library doesn't know Char and many other types are instances of Typeable anymore. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11251> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13365: Kind-inference for poly-kinded GADTs
by GHC 04 Oct '18

04 Oct '18

#13365: Kind-inference for poly-kinded GADTs -------------------------------------+------------------------------------- Reporter: crockeea | 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: -------------------------------------+------------------------------------- With `-XPolyKinds`, GADTs require kind signatures where they should be inferred. Moreover, the error when these kind sigs are omitted is baffling. {{{ {-# LANGUAGE PolyKinds, GADTs #-} import GHC.TypeLits data C (x :: k) a where C1 :: (KnownNat x) => a -> Foo x a C2 :: a -> Foo Int a }}} {{{ error: • Expected kind ‘k’, but ‘x1’ has kind ‘Nat’ • In the first argument of ‘Foo’, namely ‘x’ In the type ‘Foo x a’ In the definition of data constructor ‘C1’ }}} From this error, I would never expect that putting a kind signature on `a` would help here. But a signature shouldn't be required at all: it's clear from the GADT constructors that `a :: *`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13365> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #15675: Type operators in existential context cannot be parsed
by GHC 04 Oct '18

04 Oct '18

#15675: Type operators in existential context cannot be parsed -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!haskell {-# LANGUAGE TypeOperators, MultiParamTypeClasses, ExistentialQuantification #-} class a + b data D1 = forall a b. (a + b) => D1 a b data D2 = forall a b. a + b => D2 a b }}} The declaration `D1` is accepted, while `D2` is rejected. There is no reason to reject `D2` except for shortcomings of the current grammar. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15675> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4