December 2018 - ghc-tickets

[GHC] #15831: DerivingVia allows bogus implicit quantification in `via` type
by GHC 14 Jan '19

14 Jan '19

#15831: DerivingVia allows bogus implicit quantification in `via` type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: deriving | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs {-# LANGUAGE DerivingVia #-} {-# LANGUAGE PolyKinds #-} module Bug where import Data.Functor.Const (Const(..)) import GHC.Exts (Any) newtype Age = MkAge Int deriving Eq via Const Int Any }}} This fails to compile with a spectacularly unhelpful error message: {{{ $ /opt/ghc/8.6.1/bin/ghc -ddump-deriv Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ==================== Derived instances ==================== Derived class instances: instance GHC.Classes.Eq Bug.Age where (GHC.Classes.==) = GHC.Prim.coerce @((Data.Functor.Const.Const GHC.Types.Int (GHC.Types.Any :: k_a24l) :: TYPE GHC.Types.LiftedRep) -> (Data.Functor.Const.Const GHC.Types.Int (GHC.Types.Any :: k_a24l) :: TYPE GHC.Types.LiftedRep) -> GHC.Types.Bool) @(Bug.Age -> Bug.Age -> GHC.Types.Bool) (GHC.Classes.==) :: Bug.Age -> Bug.Age -> GHC.Types.Bool (GHC.Classes./=) = GHC.Prim.coerce @((Data.Functor.Const.Const GHC.Types.Int (GHC.Types.Any :: k_a24l) :: TYPE GHC.Types.LiftedRep) -> (Data.Functor.Const.Const GHC.Types.Int (GHC.Types.Any :: k_a24l) :: TYPE GHC.Types.LiftedRep) -> GHC.Types.Bool) @(Bug.Age -> Bug.Age -> GHC.Types.Bool) (GHC.Classes./=) :: Bug.Age -> Bug.Age -> GHC.Types.Bool Derived type family instances: Bug.hs:9:12: error: The exact Name ‘k’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful | 9 | deriving Eq | ^^ Bug.hs:9:12: error: The exact Name ‘k’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful | 9 | deriving Eq | ^^ Bug.hs:9:12: error: The exact Name ‘k’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful | 9 | deriving Eq | ^^ Bug.hs:9:12: error: The exact Name ‘k’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful | 9 | deriving Eq | ^^ }}} There are two things that are strange here: * Notice that in the derived `Eq` instance, there are references to `(GHC.Types.Any :: k_a24l)`, where `k_a24l` is completely free! This should never happen, and is almost surely the cause of the resulting volley of errors. * It's quite odd that we didn't reject this `deriving` clause outright //before// generating the derived code. In fact, if we explicitly mention the kind `k`: {{{#!hs newtype Age = MkAge Int deriving Eq via Const Int (Any :: k) }}} //Then// it's rejected properly: {{{ $ /opt/ghc/8.6.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:12: error: Type variable ‘k’ is bound in the ‘via’ type ‘Const Int (Any :: k)’ but is not mentioned in the derived class ‘Eq’, which is illegal | 9 | deriving Eq | ^^ }}} Something about implicit quantification must be sneaking by this validity check. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15831> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15010: Application (warp) server crashing periodically with "TSO object entered"
by GHC 14 Jan '19

14 Jan '19

#15010: Application (warp) server crashing periodically with "TSO object entered" -------------------------------------+------------------------------------- Reporter: ramirez7 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Runtime | Version: 8.0.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We are seeing one of our warp servers periodically crash with the following error: {{{ Apr 06 10:44:28 stdouterr.log: binary-name-elided: internal error: TSO object entered! Apr 06 10:44:28 stdouterr.log: (GHC version 8.0.2 for x86_64_unknown_linux) }}} We are sometimes seeing CPU/memory spikes concurrently with this error, but not always. We are running very similar servers for other applications and they are '''not''' experiencing this error. But this server is one of our highest- load ones. Other tickets I found with this error: * https://ghc.haskell.org/trac/ghc/ticket/12383 * https://ghc.haskell.org/trac/ghc/ticket/8316 But these seem to be happening in ghci and ghc itself, not in a binary compiled by ghc. Questions I have: * What exactly is this error? * Is there anything else we can do on our side to help debug? Any artifacts that should be produced upon crash? * Should we consider upgrading our GHC version from 8.0.2 to get a bugfix? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15010> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14645: Allow type family in data family return kind
by GHC 14 Jan '19

14 Jan '19

#14645: Allow type family in data family return kind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC currently allows {{{#!hs data family DF1 :: k1 -> k2 }}} where it's expected (and checked) that all data ''instances'' have a return kind of `Type`. (Perhaps `k2` expands to `Type -> Type`, for example.) However, it rejects {{{#!hs type family TF (x :: Type) :: Type data family DF2 :: x -> TF x }}} when that's clearly just as sensible as the first definition. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14645> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15839: DerivingStrategies defaulting warning has no associated enable/suppress flag
by GHC 14 Jan '19

14 Jan '19

#15839: DerivingStrategies defaulting warning has no associated enable/suppress flag -------------------------------------+------------------------------------- Reporter: tejon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When `DerivingStrategies`, `DeriveAnyClass` and `GeneralizedNewtypeDeriving` are enabled together, an instance that could be derived with either `newtype` or `anyclass` throws a warning when no strategy is specified. It appears to be impossible to suppress this warning. Even `-w` doesn't work! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15839> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16054: Unable to build stage3 with hadrian
by GHC 14 Jan '19

14 Jan '19

#16054: Unable to build stage3 with hadrian -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- It seems that stage3 is unsupported by hadrian. I am trying to build the target `_build/stage2/bin/ghc` but it is reported as an unknown program. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16054> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16089: seq is not cooperating with :sprint in GHCi as expected
by GHC 13 Jan '19

13 Jan '19

#16089: seq is not cooperating with :sprint in GHCi as expected -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Keywords: seq sprint | Operating System: Linux strictness | Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was playing around with strictness and performed following test: {{{#!hs Prelude> x = [True, False] Prelude> :sprint x x = _ Prelude> x `seq` True True Prelude> :sprint x x = _ }}} I completely don't understand why `x = _` at this moment. `seq` must evaluate one level of `x` achieving `x = True : _` to ensure that it is not `undefined`, so why is this information lost? I am testing it on GHCi version 8.6.3, but it is not reproducible on other versions (checked on 8.4.4, 8.2.2 and 7._._). I have asked about it on SO, so if this behavior is intended I kindly ask for explaination here [https://stackoverflow.com/questions/53898220 /sprint-and-seq-together-missing-evaluation] to let others know. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16089> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #10271: Typed Template Haskell splice difficulty when resolving overloading
by GHC 11 Jan '19

11 Jan '19

#10271: Typed Template Haskell splice difficulty when resolving overloading -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- J Garrett Morris describes the following surprising behaviour for typed Template Haskell {{{ {-# LANGUAGE TemplateHaskell, FlexibleInstances #-} module PrintfLib where import Language.Haskell.TH class Printf t where printf :: String -> Q (TExp String) -> Q (TExp t) instance Printf [Char] where tf s t | '%' `notElem` s = [|| $$t ++ s ||] | otherwise = fail ("Unexpected format %" ++ [c]) where (_, _:c:_) = break ('%' ==) s instance Printf t => Printf (Char -> t) where printf s t | c /= 'c' = fail ("Unexpected format %" ++ [c] ++ " for character") | otherwise = [|| \c -> $$(printf s'' [|| $$t ++ s' ++ [c] ||]) ||] where (s', '%':c:s'') = break ('%' ==) s ------------------------- {-# LANGUAGE TemplateHaskell #-} module Printf where import PrintfLib f :: Char -> String f = $$(printf "foo %c" [||""||]) h :: Char -> String h y = $$(printf "foo %c" [||""||]) y }}} Oddly, `f` typechecks but `h` does not, even though `h` is just an eta- expanded version of `f`: {{{ Printf.hs:9:10: No instance for (Printf t0) arising from a use of ‘printf’ The type variable ‘t0’ is ambiguous Note: there are several potential instances: instance Printf t => Printf (Char -> t) -- Defined in ‘PrintfLib’ instance Printf [Char] -- Defined in ‘PrintfLib’ In the expression: printf "foo %c" [|| "" ||] }}} What is going on? Here's the deal * To run the splice, GHC must solve any constraints that arise form the expression `(printf "foo %c" ...)`. * Since `printf` is overloaded, and overloaded on its result type, the type needed by the context of the splice is what determines which instance of `Printf` is needed. * In `f` the context needs `Char -> String`, and so the call to `printf` must have type `TExpr (Char -> String)`, so we get the constraint `Printf (Char -> String)` which we can solve. * But in `h` the rule for application tries to ''infer'' a type for the splice. So the context for the call just says `TExp t0` for some unification variable `t0`; and that leads to the insoluble constraint. You may say that GHC should be cleverer, and push that type signature information into the application. And perhaps it should. But you can never win. For example: {{{ hard x = [ $$(printf "gluk" [|| "" ||]), undefined :: Char -> String ] }}} Here the RHS of `hard` is a 2-element list. Since all elements of a list have the same type, the splice must have the same type as the second element of the list, namely `Char->String`. But seeing that would mean that we'd have to typecheck right-to-left. In general GHC tries very very hard NOT to depend on traveral order. There is no way in general to ensure that we have all the information now that constraint solving may ultimately produce. I'm not sure what to do about this. * It seldom matters, because resolving the overloading on the splice seldom depends on the result type. * When it does matter, you can fix it by giving a type signature to the splice itself. But it seems unsatisfactory. Ideas welcome. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10271> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12488: Explicit namespaces doesn't enforce namespaces
by GHC 11 Jan '19

11 Jan '19

#12488: Explicit namespaces doesn't enforce namespaces -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- It seems to me that the type keyword should permanently enforce that a RdrName lives in a particular namespace. Currently it only acts as a syntactic marker so that type constructors which looks like variables can be included in export lists. The following example is accepted by GHC. As `A` is parsed as a type constructor but later put into the data constructor namespace. {{{#!hs {-# LANGUAGE ExplicitNamespaces #-} {-# LANGUAGE TypeFamilies #-} module M ( T (type A) ) where data T = A class Foo a where type A a foo :: a -> Int }}} The fix is to track uses of ExplicitNamespaces in the AST and then use this information in the renamer. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12488> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11610: Remove IEThingAll constructor from IE datatype
by GHC 11 Jan '19

11 Jan '19

#11610: Remove IEThingAll constructor from IE datatype -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- It seems that now `IEThingWith` can include a wildcard that the `IEThingAll` constructor is a special case. I'm not sure how involved this would be but it seems worth doing. {{{ | IEThingAll (Located name) -- ^ Class/Type plus all methods/constructors -- -- - 'ApiAnnotation.AnnKeywordId's : 'ApiAnnotation.AnnOpen', -- 'ApiAnnotation.AnnDotdot','ApiAnnotation.AnnClose', -- 'ApiAnnotation.AnnType' -- For details on above see note [Api annotations] in ApiAnnotation -- See Note [Located RdrNames] in HsExpr | IEThingWith (Located name) IEWildcard [Located name] [Located (FieldLbl name)] -- ^ Class/Type plus some methods/constructors -- and record fields; see Note [IEThingWith] -- - 'ApiAnnotation.AnnKeywordId's : 'ApiAnnotation.AnnOpen', -- 'ApiAnnotation.AnnClose', -- 'ApiAnnotation.AnnComma', -- 'ApiAnnotation.AnnType' -- For details on above see note [Api annotations] in ApiAnnotation }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11610> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15835: Internal error when splicing value constructed using typed template haskell
by GHC 11 Jan '19

11 Jan '19

#15835: Internal error when splicing value constructed using typed template haskell -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Related to #15833 Compiling Test.hs leads to an internal compiler error. https://gist.github.com/f04a613bb5e20c241c5b91c2f38b8f06 {{{ {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Test where import qualified Compiler as C main :: IO () main = do $$(C.runQuery) }}} {{{ {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# OPTIONS_GHC -Wall #-} module Compiler where import Language.Haskell.TH type QTExp a = Q (TExp a) fix :: (a -> a) -> a fix f = let x = f x in x while :: forall m . Monoid m => QTExp (IO m -> IO m) -> QTExp (IO m) while b = [|| fix (\r -> whenM @(IO m) ($$b r)) ||] whenM :: Monoid m => m -> m whenM _ = mempty execOp :: forall m . Monoid m => QTExp (IO m) execOp = while [|| \r -> $$(while @m [|| id ||]) >> r ||] runQuery :: QTExp (IO ()) runQuery = execOp }}} Leads to the following internal errors even though `Compiler` type checked. {{{ Prelude> :r [1 of 2] Compiling Compiler ( Compiler.hs, interpreted ) [2 of 2] Compiling Test ( Test.hs, interpreted ) Test.hs:9:6-15: Splicing expression C.runQuery ======> C.fix (\ r_a7K7 -> (C.whenM @(IO m_a7Gp)) ((\ r_a7K8 -> ((C.fix (\ r_a7K9 -> (C.whenM @(IO m_a7Gp)) (id r_a7K9))) >> r_a7K8)) r_a7K7)) Test.hs:9:6: error: • The exact Name ‘m’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful • In the result of the splice: $C.runQuery To see what the splice expanded to, use -ddump-splices In the Template Haskell splice $$(C.runQuery) In a stmt of a 'do' block: $$(C.runQuery) | 9 | $$(C.runQuery) | ^^^^^^^^^^ Test.hs:9:6: error: • The exact Name ‘m’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful • In the result of the splice: $C.runQuery To see what the splice expanded to, use -ddump-splices In the Template Haskell splice $$(C.runQuery) In a stmt of a 'do' block: $$(C.runQuery) | 9 | $$(C.runQuery) | ^^^^^^^^^^ Test.hs:9:6: error: • GHC internal error: ‘m’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [a7K7 :-> Identifier[r_a7K7::a0, NotLetBound], r5Fg :-> Identifier[main::IO (), TopLevelLet [] True]] • In the first argument of ‘IO’, namely ‘m’ In the type ‘(IO m)’ In the expression: (C.whenM @(IO m)) ((\ r_a7K8 -> ((C.fix (\ r_a7K9 -> (C.whenM @(IO m)) (id r_a7K9))) >> r_a7K8)) r_a7K7) | 9 | $$(C.runQuery) | }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15835> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2