December 2016 - ghc-tickets

[GHC] #10600: -fwarn-incomplete-patterns doesn't work with -fno-code
by GHC 05 Jun '17

05 Jun '17

#10600: -fwarn-incomplete-patterns doesn't work with -fno-code -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- `-fwarn-incomplete-patterns` doensn't seem to generate any warnings when `-fno-code` is specified. To reproduce, save this module as `foo.hs`. {{{#!hs module Foo where foo True = 4 }}} and compile with `-fwarn-incomplete-patterns`, with and without `-fno- code`. {{{ % ghc -fwarn-incomplete-patterns -fforce-recomp foo.hs [1 of 1] Compiling Foo ( foo.hs, foo.o ) foo.hs:2:1: Warning: Pattern match(es) are non-exhaustive In an equation for ‘foo’: Patterns not matched: False % ghc -fwarn-incomplete-patterns -fforce-recomp -fno-code foo.hs [1 of 1] Compiling Foo ( foo.hs, nothing ) % }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10600> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #11032: Missing result type handling for State# s in foreign import prim.
by GHC 02 Jun '17

02 Jun '17

#11032: Missing result type handling for State# s in foreign import prim. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (FFI) | 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: -------------------------------------+------------------------------------- I've been using `foreign import prim` for a while now to craft custom primops on an as-needed basis. Attempting to write {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} {-# LANGUAGE UnliftedFFITypes #-} {-# LANGUAGE GHCForeignImportPrim #-} {-# LANGUAGE ForeignFunctionInterface #-} foreign import prim "pinThreadzh" pinThread# :: State# s -> (# State# s, Int#, Int# #) foreign import prim "unpinThreadzh" unpinThread# :: State# s -> State# s }}} threw me for a loop when it didn't work. The former works fine. The latter complains that `State# s` isn't a valid result type! {{{ src/Concurrent/Internal/Thread.hs:23:1: Unacceptable result type in foreign declaration: ‘State# s’ cannot be marshalled in a foreign call When checking declaration: foreign import prim safe "static unpinThreadzh" unpinThread# :: State# s -> State# s }}} Builtin primitives work this way all the time, so I'm guessing we just missed it in a case statement somewhere inside the compiler when dealing with `foreign import prim` support. I can likely hack around it by giving back something like `(# State# s #)` for now but that is a rather unsatisfying solution. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11032> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12499: Support multiple library import libs
by GHC 02 Jun '17

02 Jun '17

#12499: Support multiple library import libs -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Our implementation of import libraries only support single library import libs. These are by far the most common ones. However it is possible to make multi library import libraries. E.g. one import library pointing to multiple dlls. `binutils` correct supports these and with #5987 GHC will be relying on them to work. It makes sense that we are able to load them in GHCi as well. This will be required for a fully working dynamic GHC on Windows. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12499> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12237: Constraint resolution vs. type family resolution vs. TypeErrors
by GHC 01 Jun '17

01 Jun '17

#12237: Constraint resolution vs. type family resolution vs. TypeErrors -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple CustomTypeErrors | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Via http://stackoverflow.com/q/37769351/477476, given the following setup: {{{#!hs {-# LANGUAGE DataKinds, TypeFamilies, TypeOperators #-} {-# LANGUAGE FlexibleContexts, MultiParamTypeClasses, UndecidableInstances #-} import Data.Proxy import GHC.TypeLits type family TEq a b where TEq a a = a TEq a b = TypeError (Text "TEq error") type family F a where F () = () F (a, b) = TEq (F a) (F b) F a = TypeError (Text "Unsupported type: " :<>: ShowType a) }}} and the following usages of `F` and `TEq`: {{{#!hs class (repr ~ F a) => C repr a foo :: (C (F a) a) => proxy a -> () foo _ = () main :: IO () main = print $ foo (Proxy :: Proxy (Int, ())) }}} This results in {{{ * No instance for (C (TEq (TypeError ...) ()) (Int, ())) arising from a use of `foo' * In the second argument of `($)', namely `foo (Proxy :: Proxy (Int, ()))' In the expression: print $ foo (Proxy :: Proxy (Int, ())) In an equation for `main': main = print $ foo (Proxy :: Proxy (Int, ())) }}} but it would be preferable to bail out earlier when `F Int` is resolved to `TypeError ...` instead of propagating that all the way to the `C` constraint. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12237> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

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