- ghc-tickets - Haskell.org

Re: [GHC] #8440: Get rid of the remaining static flags
by GHC 27 May '17

27 May '17

#8440: Get rid of the remaining static flags -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2839, Wiki Page: | Phab:D3615 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: Phab:D2839 => Phab:D2839, Phab:D3615 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8440#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8440: Get rid of the remaining static flags
by GHC 27 May '17

27 May '17

#8440: Get rid of the remaining static flags -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2839 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: closed => new * resolution: fixed => Comment: Oops, it looks like there are still a couple of references to static flags in the flag reference. I've submitted Phab:D3615 for this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8440#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13735: RankNTypes don't work with PatternSynonyms
by GHC 27 May '17

27 May '17

#13735: RankNTypes don't work with PatternSynonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs data PLambda a = Var a | Int Int | Bool Bool | If (PLambda a) (PLambda a) (PLambda a) | Add (PLambda a) (PLambda a) | Mult (PLambda a) (PLambda a) | Eq (PLambda a) (PLambda a) | Lam (a -> PLambda a) | App (PLambda a) (PLambda a) newtype Lam = L { un :: forall a. PLambda a } }}} {{{#!hs llam :: (forall a. a -> PLambda a) -> Lam llam f = L (Lam f) }}} works fine, but does not with pattern synonyms: {{{ -- $ ghci -ignore-dot-ghci tirr.hs -- GHCi, version 8.2.0.20170507: http://www.haskell.org/ghc/ :? for help -- [1 of 1] Compiling Main ( tirr.hs, interpreted ) -- -- tirr.hs:20:25: error: -- • Couldn't match expected type ‘forall a. a -> PLambda a’ -- with actual type ‘a0 -> PLambda a0’ -- • In the declaration for pattern synonym ‘LLam’ -- • Relevant bindings include -- a :: a0 -> PLambda a0 (bound at tirr.hs:20:25) -- | -- 20 | pattern LLam a = L (Lam a) -- | ^ -- Failed, modules loaded: none. -- Prelude> pattern LLam :: (forall a. a -> PLambda a) -> Lam pattern LLam a = L (Lam a) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13735> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12991: panic when using IrredPreds in a type checker plugin.
by GHC 27 May '17

27 May '17

#12991: panic when using IrredPreds in a type checker plugin. -------------------------------------+------------------------------------- Reporter: owen | Owner: 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: -------------------------------------+------------------------------------- I'm working on a type checker plugin that solves constraints expressed with an empty, closed type family of kind Constraint. These show up in the plugin as wanted IrredPred constraints. Unfortunately, something seems to go sideways sometimes when I give solved or unsolvable IrredPreds back to GHC. I've managed to reproduce the error in a minimal-ish plugin. It doesn't try to solve anything, it just returns all the IrredPred constraints back to GHC in a TcPluginContradiction. When compiling a test case that uses the type family in a constraint, it gives the following output: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): StgCmmEnv: variable not found $dMonad_a5fm local binds for: $trModule $trModule1_r5qI $trModule2_r5rc }}} If I omit the IrredPreds and return an empty TcPluginContradiction, I get 'Could not deduce...' errors as I would expect. Strangley, the panic also goes away if I give an explicit type signature to main in the test case. I'm attaching an archive with 3 files. Plugin.hs has the plugin itself. Compare.hs has the closed type family. The test case that exercises the panic is in Fails.hs. Running {{{ ghc -shared -dynamic --make Test/*.hs -package ghc-8.0.1 }}} in the unpacked directory should reproduce the panic. Adding -dcore-lint does give some potentially useful information: {{{ [3 of 3] Compiling Test.Fails ( Test/Fails.hs, Test/Fails.o ) irred compare [W] irred_a5qq :: l_a5fo[tau:3] ≽ l'_a5fp[tau:3] (CNonCanonical) irred compare [W] irred_a5qr :: l'_a5fp[tau:3] ≽ l_a5fo[tau:3] (CNonCanonical) <no location info>: warning: In the expression: return @ m_a5fl $dMonad_a5fm @ () $dMonad_a5fm :: Monad m_a5fl[tau:3] [LclId, Str=DmdType] is out of scope <no location info>: warning: In the expression: (irred_a5qq, irred_a5qr) irred_a5qq :: s_a5ql[fuv:2] [LclId, Str=DmdType] is out of scope <no location info>: warning: In the expression: (irred_a5qq, irred_a5qr) Argument value doesn't match argument type: Fun type: (Integer ≽ Integer, Integer ≽ Integer) => (Integer ≽ Integer, Integer ≽ Integer) Arg type: s_a5ql[fuv:2] Arg: irred_a5qq *** Offending Program *** $trModule :: Module [LclIdX, Str=DmdType] $trModule = Module (TrNameS "main"#) (TrNameS "Test.Fails"#) oops :: forall l_a572 l'_a573. (l_a572 === l'_a573) => l_a572 -> l'_a573 -> () [LclIdX, Str=DmdType] oops = \ (@ l_a5eW) (@ l'_a5eX) _ [Occ=Dead] _ [Occ=Dead] _ [Occ=Dead] -> () main :: forall (m_a5fl :: * -> *). m_a5fl () [LclIdX, Str=DmdType] main = \ (@ (m_a5fl :: * -> *)) -> $ @ 'PtrRepLifted @ () @ (m_a5fl ()) (return @ m_a5fl $dMonad_a5fm @ ()) (oops @ Integer @ Integer (irred_a5qq, irred_a5qr) 1 0) *** End of Offense *** <no location info>: error: Compilation had errors }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12991> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12648: Stack overflow when using monad-unlift
by GHC 27 May '17

27 May '17

#12648: Stack overflow when using monad-unlift -------------------------------------+------------------------------------- Reporter: nh2 | Owner: 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 Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found that with the following simple program I could make runghc/ghci crash with `*** Exception: stack overflow`: {{{ #!/usr/bin/env stack -- stack --resolver lts-7.1 --install-ghc runghc --package monad- unlift-0.2.0 {-# LANGUAGE FlexibleContexts #-} import Control.Monad.Trans.Unlift f :: (MonadBaseUnlift m IO) => m a f = do _ <- askUnliftBase return () }}} I'm not super sure if that's OK. Probably not; even if it does trigger an undecideable case, shouldn't ghc tell me about it instead of just crashing? The `monad-unlift` code used is here: https://github.com/fpco/monad- unlift/blob/adb7869adccc66247cbb1a6175277802e9c098e1/monad- unlift/Control/Monad/Trans/Unlift.hs -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12648> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12175: Instance resolution regression
by GHC 27 May '17

27 May '17

#12175: Instance resolution regression -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- The following code works in 7.10, but fails in GHC 8.0.1: {{{ {-# LANGUAGE ConstraintKinds, MultiParamTypeClasses, TypeFamilies, UndecidableInstances #-} import GHC.Exts class Foo a instance (Foo a, Foo b, CTypeOf a ~ CTypeOf b) => Foo (a,b) type family TElt r :: Constraint type instance TElt r = (Foo r, Dispatch (CTypeOf r) r) type family CTypeOf x where CTypeOf (a,b) = CTypeOf a class (repr ~ CTypeOf r) => Dispatch repr r data CT r = CT [r] toCT :: (Foo r) => CT r -> CT r toCT = undefined unzipT :: (TElt a, TElt b, TElt (a,b)) => CT (a,b) -> (CT a, CT b) unzipT = unzipT . toCT main :: IO () main = undefined }}} with the errors {{{ Main.hs:1:1: error: solveWanteds: too many iterations (limit = 4) Unsolved: WC {wc_simple = [D] _ :: Dispatch fsk_a3GC b (CDictCan) [W] hole{a3Hh} :: CTypeOf a ~ CTypeOf b (CNonCanonical) [D] _ :: fsk_a3GC ~ CTypeOf b (CDictCan) [D] _ :: fsk_a3GC ~ CTypeOf b (CDictCan) [D] _ :: fsk_a3GC ~ CTypeOf b (CNonCanonical)} New superclasses found Set limit with -fconstraint-solver-iterations=n; n=0 for no limit Main.hs:22:19: error: • Couldn't match type ‘CTypeOf a’ with ‘CTypeOf b’ arising from a use of ‘toCT’ NB: ‘CTypeOf’ is a type function, and may not be injective • In the second argument of ‘(.)’, namely ‘toCT’ In the expression: unzipT . toCT In an equation for ‘unzipT’: unzipT = unzipT . toCT • Relevant bindings include unzipT :: CT (a, b) -> (CT a, CT b) (bound at Main.hs:22:1) }}} I don't understand the first error at all. The second error seems to be due to calling `toCT` on the type `CT (a,b)`, which requires the constraint `Foo (a,b)`. Rather than using the supplied constraint from `TElt (a,b)`, GHC is trying to resolve the instance provided, which requires `CType a ~ CType b`. Possibly related: #10338, #11948 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12175> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13758: Deriving can't find an instance that holds, standalone deriving works
by GHC 26 May '17

26 May '17

#13758: Deriving can't find an instance that holds, standalone deriving works -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: -------------------------------------+------------------------------------- Using [https://hackage.haskell.org/package/generic-deriving-1.11.2/docs /Generics-Deriving-Monoid.html generic-deriving] works {{{#!hs {-# Language ScopedTypeVariables, GeneralizedNewtypeDeriving, DeriveGeneric, UndecidableInstances, StandaloneDeriving, FlexibleContexts #-} import GHC.Generics import Generics.Deriving.Monoid hiding (GMonoid) import Data.Coerce import Data.Constraint import Data.Semigroup newtype GenericMonoid a = GenericMonoid a instance (Generic a, Monoid' (Rep a)) => Semigroup (GenericMonoid a) where (<>) = coerce (mappenddefault :: a -> a -> a) instance (Generic a, Monoid' (Rep a)) => Monoid (GenericMonoid a) where mempty = coerce (memptydefault :: a) mappend = coerce (mappenddefault :: a -> a -> a) data Urls = Urls String String String deriving (Show, Generic) newtype UrlsDeriv = UD (GenericMonoid Urls) deriving instance Semigroup UrlsDeriv deriving instance Monoid UrlsDeriv }}} but changing that to {{{#!hs newtype UrlsDeriv = UD (GenericMonoid Urls) deriving (Semigroup, Monoid) }}} fails {{{ $ ghci -ignore-dot-ghci tWqD.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( tWqD.hs, interpreted ) Ok, modules loaded: Main. *Main> :r [1 of 1] Compiling Main ( tWqD.hs, interpreted ) tWqD.hs:26:13: error: • No instance for (Monoid' (Rep Urls)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself • When deriving the instance for (Semigroup UrlsDeriv) tWqD.hs:26:24: error: • No instance for (Monoid' (Rep Urls)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself • When deriving the instance for (Monoid UrlsDeriv) Failed, modules loaded: none. }}} This feels familiar but I couldn't quickly. I can't recall if this behavior is intended so I'm filing a ticket just in case. It even following proof of `Monoid' (Rep Urls)` and a dummy quasiquote `pure []` separating it them, {{{#!hs {-# Language ..., TemplateHaskell #-} ... doo :: Dict (Monoid' (Rep Urls)) doo = Dict pure [] newtype UrlsDeriv = UD (GenericMonoid Urls) deriving Monoid }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13758> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF
by GHC 26 May '17

26 May '17

#8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF ------------------------------+-------------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- The code generator unnecessarily spills and reloads function arguments if the scrutinee turns out to be already evaluated (i.e. has non-zero tag bits). Here's the beginning of a function body, taken from the `insert` function at https://github.com/tibbe/unordered- containers/blob/master/Data/HashMap/Base.hs#L303: {{{ c2wQ: // stack check if ((Sp + -72) < SpLim) goto c2wR; else goto c2wS; c2wR: // stack check failure R1 = PicBaseReg + $wpoly_go_closure; I64[Sp - 40] = R2; I64[Sp - 32] = R3; P64[Sp - 24] = R4; I64[Sp - 16] = R5; P64[Sp - 8] = R6; Sp = Sp - 40; call (I64[BaseReg - 8])(R1) args: 48, res: 0, upd: 8; c2wS: // stack check success I64[Sp - 40] = PicBaseReg + block_c2my_info; // return addr for eval R1 = R6; // t I64[Sp - 32] = R2; // spill: s I64[Sp - 24] = R3; // spill: x P64[Sp - 16] = R4; // spill: k I64[Sp - 8] = R5; // spill: h Sp = Sp - 40; if (R1 & 7 != 0) goto c2my; else goto c2mz; // eval check of t c2mz: // eval check failed call (I64[R1])(R1) returns to c2my, args: 8, res: 8, upd: 8; // eval c2my: // eval check succeeded _s2b1::I64 = I64[Sp + 8]; // reload: h _s2b2::I64 = I64[Sp + 16]; // reload: k _s2b3::P64 = P64[Sp + 24]; // reload: x _s2b4::I64 = I64[Sp + 32]; // reload: s switch [0 .. 4] (R1 & 7 - 1) { case 0 : goto c2wK; case 1 : goto c2wL; case 2 : goto c2wM; case 3 : goto c2wN; case 4 : goto c2wO; } }}} It seems to me that all the spills/reloads could be pushed into the `c2mz` block. The `c2my` block, in its current form, is reused for a heap check failure case, so the heap check most likely will have to do its own spilling/reloading. However, since the scrutinee not having tags bit or the eval checking failing is not the common case, they should be out of the common path. If it matters the data type is spine strict so GHC should have enough information to know that the common case (e.g. self-recursive calls) already have an evaluated argument (although there might be an indirection in some cases). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8905> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #10421: exponential blowup in inlining (without INLINE pragmas)
by GHC 26 May '17

26 May '17

#10421: exponential blowup in inlining (without INLINE pragmas) -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The test case for #10397 also demonstrates an exponential blowup by the inliner, without any INLINE pragmas. I added another four fields to the `Register` type, and I get these final Core program sizes. (The variation in sizes between versions is not really important, the point is just that they are very large for all versions.) {{{ ghc-7.6.3: *** CorePrep: Result size of CorePrep = {terms: 1,702,684, types: 1,950,647, coercions: 103} ghc-7.8.4: *** CorePrep: Result size of CorePrep = {terms: 1,964,183, types: 1,950,620, coercions: 97} ghc-7.10.1: *** CorePrep: Result size of CorePrep = {terms: 1,964,212, types: 1,950,764, coercions: 97} ghc-7.11: *** CorePrep: Result size of CorePrep = {terms: 1,964,212, types: 1,950,764, coercions: 97} }}} Ideally GHC should not produce enormous Core programs on its own like this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10421> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13677: Incorrect parenthesization of type in error message
by GHC 26 May '17

26 May '17

#13677: Incorrect parenthesization of type in error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | 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: -------------------------------------+------------------------------------- If you compile this program: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE GADTs #-} import GHC.Exts (Constraint) data Dict a where Dict :: a => Dict a foo :: Dict (Int ~ Int) => Int foo = undefined }}} In GHC 8.0.1, 8.0.2, 8.2.1, or HEAD, it will give this error message: {{{ GHCi, version 8.3.20170509: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug2.hs, interpreted ) Bug2.hs:9:8: error: • Expected a constraint, but ‘Dict Int ~ Int’ has kind ‘*’ • In the type signature: foo :: Dict (Int ~ Int) => Int | 9 | foo :: Dict (Int ~ Int) => Int | ^^^^^^^^^^^^^^^^ }}} But `Dict Int ~ Int` is not parenthesized correctly! This is a regression, as GHC 7.10.3 and earlier parenthesize it correctly: {{{ GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Bug2.hs, interpreted ) Bug2.hs:9:8: Expected a constraint, but ‘Dict (Int ~ Int)’ has kind ‘*’ In the type signature for ‘foo’: foo :: Dict (Int ~ Int) => Int }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13677> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7