February 2017 - ghc-tickets

[GHC] #12820: Regression around pattern synonyms and higher-rank types
by GHC 30 May '17

30 May '17

#12820: Regression around pattern synonyms and higher-rank types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | 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: -------------------------------------+------------------------------------- GHC 8.0.1 accepts, but HEAD rejects: {{{#!hs {-# LANGUAGE PatternSynonyms, RankNTypes, ViewPatterns #-} module Bug where pattern P :: (forall a. a -> a) -> String pattern P x <- (\ _ -> id -> x) }}} (Sidenote: kudos to the parser on figuring out my view pattern.) HEAD gives this error: {{{ Bug.hs:6:30: error: • Couldn't match expected type ‘forall a. a -> a’ with actual type ‘a0 -> a0’ • In the declaration for pattern synonym ‘P’ • Relevant bindings include x :: a0 -> a0 (bound at Bug.hs:6:30) }}} The code looks correct to me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12820> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12908: Tuple constraints refactoring seems to regress performance considerably
by GHC 30 May '17

30 May '17

#12908: Tuple constraints refactoring seems to regress performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: performance | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ffc21506894c7887d3620423aaf86bc6113a1071 seems to cause compiler runtime regression as large as 15%. This deserves some attention. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12908> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11834: GHC master, not compiling on Archlinux
by GHC 29 May '17

29 May '17

#11834: GHC master, not compiling on Archlinux -------------------------------------+------------------------------------- Reporter: nitrix | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Linking) | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- /usr/bin/ld: -r and -pie may not be used together http://lpaste.net/159726 It appears on Archlinux, with GCC version 5.3.0, there's an implicit -pie flag passed to `ld`. I looked into compiler/main/DriverPipeline.hs at joinObjectFiles, it is unconditionally doing "-Wl,-r", thus the error above. One suggested fix on IRC is to modify getCompilerInfo to know if it supports -no-pie, then add it to the flags that are used. I tried and got somewhere lost in compiler/main/DynFlags.hs. (Completely new to GHC) Hopefully someone can figure it out, it seems important for development and I really want to get involved :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11834> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13306: Problems with type inference for static expressions
by GHC 29 May '17

29 May '17

#13306: Problems with type inference for static expressions -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- I've been running into some difficulties with type inference for static expressions; I suspect not enough type information might be propagated down. Below are a number of tests, all of which compare type inference for `static` with type inference for a function {{{#!hs fakeStatic :: Typeable a => a -> StaticPtr a fakeStatic = undefined }}} Apart from syntactic checks, I'd expect `static <expr>` and `fake`Static <expr>` to behave more or less the same, but they don't. Here are some examples: {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StaticPointers #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE GADTs #-} module Main where import Data.Proxy import Data.Typeable import GHC.StaticPtr {------------------------------------------------------------------------------- Setup -------------------------------------------------------------------------------} -- Some kind of non-injective type family type family NonInj a where NonInj Bool = () NonInj Char = () -- To compare against the real static fakeStatic :: Typeable a => a -> StaticPtr a fakeStatic = undefined {------------------------------------------------------------------------------- Test 1: identity function -------------------------------------------------------------------------------} f1 :: Proxy a -> NonInj a -> NonInj a f1 Proxy = id f2 :: forall a. Typeable (NonInj a) => Proxy a -> StaticPtr (NonInj a -> NonInj a) f2 Proxy = fakeStatic id -- Fails with: -- -- Couldn't match type ‘a0’ with ‘NonInj a’ -- Expected type: NonInj a -> NonInj a -- Actual type: a0 -> a0 -- The type variable ‘a0’ is ambiguous -- f3 :: forall a. Typeable (NonInj a) => Proxy a -> StaticPtr (NonInj a -> NonInj a) -- f3 Proxy = static id -- Fails with the same error -- f4 :: forall a. Typeable (NonInj a) => Proxy a -> StaticPtr (NonInj a -> NonInj a) -- f4 Proxy = (static id) :: StaticPtr (NonInj a -> NonInj a) {------------------------------------------------------------------------------- Test 2: adding some kind of universe -------------------------------------------------------------------------------} data U :: * -> * where UB :: U Bool UC :: U Char f5 :: U a -> NonInj a -> NonInj a f5 _ = id -- This works just fine f6 :: (Typeable a, Typeable (NonInj a)) => StaticPtr (U a -> NonInj a -> NonInj a) f6 = static f5 -- but if we introduce Typeable .. f7 :: Typeable a => U a -> NonInj a -> NonInj a f7 _ = id -- .. fakeStatic still works f8 :: (Typeable a, Typeable (NonInj a)) => StaticPtr (U a -> NonInj a -> NonInj a) f8 = fakeStatic f7 -- .. but static leads to a weird error: -- No instance for (Typeable a) arising from a use of ‘f7’ -- f9 :: (Typeable a, Typeable (NonInj a)) => StaticPtr (U a -> NonInj a -> NonInj a) -- f9 = static f7 {------------------------------------------------------------------------------- Test 3: GADT wrapping StaticPtr -------------------------------------------------------------------------------} data Static :: * -> * where StaticPtr :: StaticPtr a -> Static a StaticApp :: Static (a -> b) -> Static a -> Static b -- Serializable types can be embedded into Static; here we just support U StaticBase :: U a -> Static (U a) -- this is fine f10 :: forall a. (Typeable a, Typeable (NonInj a)) => U a -> Static (NonInj a -> NonInj a) f10 x = StaticPtr (fakeStatic f5) `StaticApp` (StaticBase x) -- but this fails with -- Couldn't match type ‘NonInj a -> NonInj a’ -- with ‘NonInj a0 -> NonInj a0’ -- Expected type: U a -> NonInj a -> NonInj a -- Actual type: U a0 -> NonInj a0 -> NonInj a0 -- f11 :: forall a. (Typeable a, Typeable (NonInj a)) => U a -> Static (NonInj a -> NonInj a) -- f11 x = StaticPtr (static f5) `StaticApp` (StaticBase x) -- although in this case we can work around it with a type annotation: -- (note that for f4 above this workaround didn't work) f12 :: forall a. (Typeable a, Typeable (NonInj a)) => U a -> Static (NonInj a -> NonInj a) f12 x = StaticPtr (static f5 :: StaticPtr (U a -> NonInj a -> NonInj a)) `StaticApp` (StaticBase x) {------------------------------------------------------------------------------- End of tests -------------------------------------------------------------------------------} main :: IO () main = putStrLn "Hi" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13306> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13238: Harmonise pretty printing of parens in hsSyn
by GHC 28 May '17

28 May '17

#13238: Harmonise pretty printing of parens in hsSyn -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- Phab:D3043 Removes the insertion of parens in the pretty printer for `HsPar`. This is motivated by making it easier to see if there is a problem with the `ppr` round trip capability introduced in #3384. Due to a lack of time, the has not been done for `ParPat` or `HsParTy`. Complete this work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13238> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[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 26 May '17

26 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 26 May '17

26 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] #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