March 2018 - ghc-tickets

[GHC] #12410: Somehow detect splicing in ghci
by GHC 02 Jul '18

02 Jul '18

#12410: Somehow detect splicing in ghci -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: 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: -------------------------------------+------------------------------------- I'm no TH expert but currently it seems you need a hack (adding `data X ;` or `pure []`) to do the following {{{ ghci> $(reify ''() >>= runIO.print >> return []) <interactive>:210:3: error: • Couldn't match type ‘[t0]’ with ‘Exp’ Expected type: ExpQ Actual type: Q [t0] • In the expression: reify ''() >>= runIO . print >> return [] In the untyped splice: $(reify ''() >>= runIO . print >> return []) }}} {{{#!hs >>> data X; $(reify ''() >>= runIO.print >> return []) TyConI (DataD [] GHC.Tuple.() [] Nothing [NormalC GHC.Tuple.() []] []) >>> pure []; $(reify ''() >>= runIO.print >> return []) TyConI (DataD [] GHC.Tuple.() [] Nothing [NormalC GHC.Tuple.() []] []) }}} Same with [https://hackage.haskell.org/package/lens-4.14/docs/Control- Lens-TH.html#v:makeLenses makeLenses] (discussed [https://artyom.me/lens- over-tea-6 here], [https://github.com/ekmett/lens/issues/461 there]): {{{ >>> data A = B { _int :: Int } >>> makeLenses ''A <interactive>:209:1: error: • No instance for (Show DecsQ) arising from a use of ‘print’ • In a stmt of an interactive GHCi command: print it }}} the following two work {{{#!hs >>> data A = B { _int :: Int } >>> pure []; makeLenses ''A >>> view int (B 42) 42 }}} {{{#!hs >>> data A = B { _int :: Int }; makeLenses ''A >>> view int (B 42) 42 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12410> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8489: clean up dependency and usages handling in interface files
by GHC 02 Jul '18

02 Jul '18

#8489: clean up dependency and usages handling in interface files ----------------------------------------------+---------------------------- Reporter: errge | Owner: errge Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Template Haskell | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: 1480 | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- While reviewing #1480, it was found that there are corner cases that are not easy to handle. This task is about fixing TH module reification to reify direct import list, not usages. For this we may need to extend the current `ModIface`. This task also includes cleaning up the comments and code in related areas, to quote simonpj: "we need more precise commentary on the fields of `HscTypes.Dependencies`, `TcRnTypes.ImportAvails`, and `mi_usages` of `ModIface`. For example, I wonder whether the `mi_usages` field could be part of the `Dependencies`". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8489> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11812: Template Haskell can induce non-unique Uniques
by GHC 02 Jul '18

02 Jul '18

#11812: Template Haskell can induce non-unique Uniques -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.1 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: -------------------------------------+------------------------------------- When quoting a Template Haskell expression (or type), you can get your hands on renamed variables. These variables have assigned Uniques. If you then use the same variable locally in ''different'' top-level expressions, chaos can ensue. It's certainly expected that something bizarre would happen if you used the same Unique twice within the same scope, but it surprised me that using the same Unique twice in different scopes would cause a problem. Below is the rather hard-won reduced test case: {{{ {-# LANGUAGE TemplateHaskell, PolyKinds, RankNTypes, TypeFamilies #-} module Bug where import Language.Haskell.TH import Data.Type.Equality type Const a b = a $( do ForallT [PlainTV n] _ _ <- [t| forall n. n |] let noBang = Bang NoSourceUnpackedness NoSourceStrictness return [ClosedTypeFamilyD (TypeFamilyHead (mkName "F1") [ KindedTV (mkName "a") (VarT n) , PlainTV (mkName "b") ] (KindSig (VarT n)) Nothing) [TySynEqn [VarT (mkName "a"), VarT (mkName "b")] (ConT ''Const `AppT` VarT (mkName "a") `AppT` (ConT (mkName "T1") `AppT` VarT (mkName "a") `AppT` VarT (mkName "b")))] ,DataD [] (mkName "T1") [ KindedTV (mkName "a") (VarT n) , PlainTV (mkName "b") , PlainTV (mkName "c")] Nothing [NormalC (mkName "K1") [(noBang, ConT ''(:~:) `AppT` VarT (mkName "c") `AppT` (ConT (mkName "F1") `AppT` VarT (mkName "a") `AppT` VarT (mkName "b")))]] []]) }}} This blob produces {{{ type family F1 (a :: n_auRf) b :: n_auRf where F1 a b = Const a (T1 a b) data T1 (a :: n_auRf) b c = K1 ((:~:) c (F1 a b)) }}} which compiles fine when typed in directly. Note that this hinges on the `SigTv` behavior of kind variables in non-CUSK declarations, but I don't think that's the nub of the problem. What happens is this: during renaming, the `n`s are renamed to have the same `Unique`, because `n` is `Exact`. Type-checking invents `SigTv`s for each `n`. Naturally, both `n`s have ''different'' `IORef`s stored in their `TcTyVarDetails`. When the two `n`s are compared during checking, though, their `Unique`s are the same, and so nothing happens -- even though they should be unified. The upshot is that we get one logical variable `n` with different `IORef`s in different occurrences, causing chaos. It might be reasonable to punt on this, but we should document in the manual what the problem is. It puzzled me for quite a while when the problem came up in real code! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11812> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14318: TH shadowing bind statement triggers -Wunused-matches
by GHC 02 Jul '18

02 Jul '18

#14318: TH shadowing bind statement triggers -Wunused-matches -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.2.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $(newName "x" >>= \x -> newName "f" >>= \f -> lamE [varP f, varP x] (doE [ bindS (varP x) (listE [varE f `appE` varE x]) , noBindS (varE x)]) ) }}} generates the following expression: {{{ \f x -> do x <- f x x }}} and `-Wunused-matches` complains that `x` is not used, while both bound occurrences are in fact used. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14318> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14858: Typed hole subtitution search fails in the REPL
by GHC 01 Jul '18

01 Jul '18

#14858: Typed hole subtitution search fails in the REPL -------------------------------------+------------------------------------- Reporter: paf31 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha3 (Type checker) | Keywords: typed holes | Operating System: Unknown/Multiple substitutions | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems as though type class defaulting might be happening before the search. This finds only undefined: {{{#!text > _traverse print "abc" <interactive>:20:1: error: • Found hole: _traverse :: (() -> IO ()) -> [Char] -> t Where: ‘t’ is a rigid type variable bound by the inferred type of it :: t at <interactive>:20:1-21 Or perhaps ‘_traverse’ is mis-spelled, or not in scope • In the expression: _traverse In the expression: _traverse print "abc" In an equation for ‘it’: it = _traverse print "abc" • Relevant bindings include it :: t (bound at <interactive>:20:1) Valid substitutions include undefined :: forall (a :: TYPE r). GHC.Stack.Types.HasCallStack => a (imported from ‘Prelude’ (and originally defined in ‘GHC.Err’)) }}} Annotating the return type helps, but we still don't find traverse_: {{{#!text > _traverse print "abc" :: IO () <interactive>:22:1: error: • Found hole: _traverse :: (() -> IO ()) -> [Char] -> IO () Or perhaps ‘_traverse’ is mis-spelled, or not in scope • In the expression: _traverse In the expression: _traverse print "abc" :: IO () In an equation for ‘it’: it = _traverse print "abc" :: IO () • Relevant bindings include it :: IO () (bound at <interactive>:22:1) Valid substitutions include mempty :: forall a. Monoid a => a (imported from ‘Prelude’ (and originally defined in ‘GHC.Base’)) undefined :: forall (a :: TYPE r). GHC.Stack.Types.HasCallStack => a (imported from ‘Prelude’ (and originally defined in ‘GHC.Err’)) }}} (note how print seems to have been defaulted to ()) Annotating the type of print helps: {{{#!text > _traverse (print :: Char -> IO ()) "abc" :: IO () <interactive>:23:1: error: • Found hole: _traverse :: (Char -> IO ()) -> [Char] -> IO () Or perhaps ‘_traverse’ is mis-spelled, or not in scope • In the expression: _traverse In the expression: _traverse (print :: Char -> IO ()) "abc" :: IO () In an equation for ‘it’: it = _traverse (print :: Char -> IO ()) "abc" :: IO () • Relevant bindings include it :: IO () (bound at <interactive>:23:1) Valid substitutions include mempty :: forall a. Monoid a => a (imported from ‘Prelude’ (and originally defined in ‘GHC.Base’)) undefined :: forall (a :: TYPE r). GHC.Stack.Types.HasCallStack => a (imported from ‘Prelude’ (and originally defined in ‘GHC.Err’)) foldMap :: forall (t :: * -> *). Foldable t => forall m a. Monoid m => (a -> m) -> t a -> m (imported from ‘Prelude’ (and originally defined in ‘Data.Foldable’)) mapM_ :: forall (t :: * -> *) (m :: * -> *) a b. (Foldable t, Monad m) => (a -> m b) -> t a -> m () (imported from ‘Prelude’ (and originally defined in ‘Data.Foldable’)) traverse_ :: forall (t :: * -> *) (f :: * -> *) a b. (Foldable t, Applicative f) => (a -> f b) -> t a -> f () (imported from ‘Data.Foldable’) }}} This was found with 8.4.1-rc.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14858> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1)
by GHC 30 Jun '18

30 Jun '18

#8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) -------------------------------------+------------------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 libraries/haskell2010 | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: Unknown/Multiple | at runtime Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- According to the documentation for Data.Int, “All arithmetic is performed modulo 2!^n, where n is the number of bits in the type.” However, this promise is broken by the following exception: {{{ Prelude> (minBound :: Int) `quot` (-1) *** Exception: arithmetic overflow }}} (This also occurs with Int8, Int16, Int32, and Int64, and likewise for `div`.) If all arithmetic is performed modulo 2!^n, I would rather expect the above to evaluate to `minBound`, since after all `minBound * (-1) == minBound`. The fact that an exception is raised adds an unnecessary burden in pure code to ensure `quot` (or `div`) is never called with these specific arguments. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8695> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 39

[GHC] #11024: Fix strange parsing of BooleanFormula
by GHC 29 Jun '18

29 Jun '18

#11024: Fix strange parsing of BooleanFormula -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | 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: -------------------------------------+------------------------------------- Consider the following program. {{{ module Foo where class Meh a where foo :: a -> String foo1 :: a -> String foo2 :: a -> String {-# MINIMAL foo, foo1, foo2 #-} }}} The minimal pragma is parsed quite weirdly. {{{ (MinimalSig "{-# MINIMAL" (And [ (Var ({ test.hs:8:15-17 } (Unqual {OccName: foo}))), (And [ (Var ({ test.hs:8:20-23 } (Unqual {OccName: foo1}))), (Var ({ test.hs:8:26-29 } (Unqual {OccName: foo2})))])])))] {Bag(Located (HsBind RdrName)):}}} To be clear, it is parsed as `And [foo, [And [foo1, foo2]]` rather than `And [foo, foo1, foo2]`. Either the datatype should be change to be more like a binary tree or the parser should be changed to handle this properly. I think the second option would be easiest. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11024> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11764: ghc internal error building llvm-general-3.5.1.2
by GHC 29 Jun '18

29 Jun '18

#11764: ghc internal error building llvm-general-3.5.1.2 -------------------------------------+------------------------------------- Reporter: andrew.wja | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: cabal install | Blocked By: llvm-general | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- $ cabal install llvm-general Resolving dependencies... Configuring llvm-general-3.5.1.2... Building llvm-general-3.5.1.2... Failed to install llvm-general-3.5.1.2 Build log ( /home/andrew/.cabal/logs/llvm-general-3.5.1.2.log ): [1 of 1] Compiling Main ( /tmp/cabal-tmp-12630/llvm- general-3.5.1.2/dist/setup/setup.hs, /tmp/cabal-tmp-12630/llvm- general-3.5.1.2/dist/setup/Main.o ) Linking /tmp/cabal-tmp-12630/llvm-general-3.5.1.2/dist/setup/setup ... Configuring llvm-general-3.5.1.2... Building llvm-general-3.5.1.2... Preprocessing library llvm-general-3.5.1.2... [ 1 of 93] Compiling LLVM.General.Internal.FFI.ByteRangeCallback ( src/LLVM/General/Internal/FFI/ByteRangeCallback.hs, dist/build/LLVM/General/Internal/FFI/ByteRangeCallback.o ) [ 2 of 93] Compiling LLVM.General.Internal.FFI.Transforms ( src/LLVM/General/Internal/FFI/Transforms.hs, dist/build/LLVM/General/Internal/FFI/Transforms.o ) [ 3 of 93] Compiling LLVM.General.Internal.Inject ( src/LLVM/General/Internal/Inject.hs, dist/build/LLVM/General/Internal/Inject.o ) [ 4 of 93] Compiling LLVM.General.Internal.FFI.Context ( src/LLVM/General/Internal/FFI/Context.hs, dist/build/LLVM/General/Internal/FFI/Context.o ) [ 5 of 93] Compiling LLVM.General.Internal.FFI.CommandLine ( src/LLVM/General/Internal/FFI/CommandLine.hs, dist/build/LLVM/General/Internal/FFI/CommandLine.o ) [ 6 of 93] Compiling LLVM.General.Internal.FFI.Iterate ( src/LLVM/General/Internal/FFI/Iterate.hs, dist/build/LLVM/General/Internal/FFI/Iterate.o ) [ 7 of 93] Compiling LLVM.General.Internal.FFI.PtrHierarchy ( src/LLVM/General/Internal/FFI/PtrHierarchy.hs, dist/build/LLVM/General/Internal/FFI/PtrHierarchy.o ) [ 8 of 93] Compiling LLVM.General.Internal.FFI.BasicBlock ( src/LLVM/General/Internal/FFI/BasicBlock.hs, dist/build/LLVM/General/Internal/FFI/BasicBlock.o ) [ 9 of 93] Compiling LLVM.General.Internal.FFI.User ( src/LLVM/General/Internal/FFI/User.hs, dist/build/LLVM/General/Internal/FFI/User.o ) [10 of 93] Compiling LLVM.General.Internal.FFI.GlobalAlias ( src/LLVM/General/Internal/FFI/GlobalAlias.hs, dist/build/LLVM/General/Internal/FFI/GlobalAlias.o ) [11 of 93] Compiling LLVM.General.Internal.FFI.LLVMCTypes ( dist/build/LLVM/General/Internal/FFI/LLVMCTypes.hs, dist/build/LLVM/General/Internal/FFI/LLVMCTypes.o ) [12 of 93] Compiling LLVM.General.Internal.FFI.Attribute ( src/LLVM/General/Internal/FFI/Attribute.hs, dist/build/LLVM/General/Internal/FFI/Attribute.o ) [13 of 93] Compiling LLVM.General.Internal.FFI.GlobalValue ( src/LLVM/General/Internal/FFI/GlobalValue.hs, dist/build/LLVM/General/Internal/FFI/GlobalValue.o ) [14 of 93] Compiling LLVM.General.Internal.FFI.Instruction ( src/LLVM/General/Internal/FFI/Instruction.hs, dist/build/LLVM/General/Internal/FFI/Instruction.o ) [15 of 93] Compiling LLVM.General.Internal.FFI.Type ( src/LLVM/General/Internal/FFI/Type.hs, dist/build/LLVM/General/Internal/FFI/Type.o ) [16 of 93] Compiling LLVM.General.Internal.FFI.Value ( src/LLVM/General/Internal/FFI/Value.hs, dist/build/LLVM/General/Internal/FFI/Value.o ) [17 of 93] Compiling LLVM.General.Internal.FFI.BinaryOperator ( src/LLVM/General/Internal/FFI/BinaryOperator.hs, dist/build/LLVM/General/Internal/FFI/BinaryOperator.o ) [18 of 93] Compiling LLVM.General.Internal.FFI.DataLayout ( src/LLVM/General/Internal/FFI/DataLayout.hs, dist/build/LLVM/General/Internal/FFI/DataLayout.o ) [19 of 93] Compiling LLVM.General.Internal.FFI.SMDiagnostic ( src/LLVM/General/Internal/FFI/SMDiagnostic.hs, dist/build/LLVM/General/Internal/FFI/SMDiagnostic.o ) [20 of 93] Compiling LLVM.General.Internal.FFI.Module ( src/LLVM/General/Internal/FFI/Module.hs, dist/build/LLVM/General/Internal/FFI/Module.o ) [21 of 93] Compiling LLVM.General.Internal.FFI.ExecutionEngine ( src/LLVM/General/Internal/FFI/ExecutionEngine.hs, dist/build/LLVM/General/Internal/FFI/ExecutionEngine.o ) [22 of 93] Compiling LLVM.General.Internal.FFI.Function ( src/LLVM/General/Internal/FFI/Function.hs, dist/build/LLVM/General/Internal/FFI/Function.o ) [23 of 93] Compiling LLVM.General.Internal.FFI.InlineAssembly ( src/LLVM/General/Internal/FFI/InlineAssembly.hs, dist/build/LLVM/General/Internal/FFI/InlineAssembly.o ) [24 of 93] Compiling LLVM.General.Internal.FFI.InstructionDefs ( dist/build/LLVM/General/Internal/FFI/InstructionDefs.hs, dist/build/LLVM/General/Internal/FFI/InstructionDefs.o ) [25 of 93] Compiling LLVM.General.Internal.InstructionDefs ( src/LLVM/General/Internal/InstructionDefs.hs, dist/build/LLVM/General/Internal/InstructionDefs.o ) [26 of 93] Compiling LLVM.General.Internal.FFI.MemoryBuffer ( src/LLVM/General/Internal/FFI/MemoryBuffer.hs, dist/build/LLVM/General/Internal/FFI/MemoryBuffer.o ) [27 of 93] Compiling LLVM.General.Internal.FFI.Metadata ( src/LLVM/General/Internal/FFI/Metadata.hs, dist/build/LLVM/General/Internal/FFI/Metadata.o ) [28 of 93] Compiling LLVM.General.Internal.FFI.GlobalVariable ( src/LLVM/General/Internal/FFI/GlobalVariable.hs, dist/build/LLVM/General/Internal/FFI/GlobalVariable.o ) [29 of 93] Compiling LLVM.General.Internal.FFI.RawOStream ( src/LLVM/General/Internal/FFI/RawOStream.hs, dist/build/LLVM/General/Internal/FFI/RawOStream.o ) [30 of 93] Compiling LLVM.General.Internal.FFI.Assembly ( src/LLVM/General/Internal/FFI/Assembly.hs, dist/build/LLVM/General/Internal/FFI/Assembly.o ) [31 of 93] Compiling LLVM.General.Internal.FFI.Bitcode ( src/LLVM/General/Internal/FFI/Bitcode.hs, dist/build/LLVM/General/Internal/FFI/Bitcode.o ) [32 of 93] Compiling LLVM.General.Internal.FFI.Target ( src/LLVM/General/Internal/FFI/Target.hs, dist/build/LLVM/General/Internal/FFI/Target.o ) [33 of 93] Compiling LLVM.General.Internal.FFI.Threading ( src/LLVM/General/Internal/FFI/Threading.hs, dist/build/LLVM/General/Internal/FFI/Threading.o ) [34 of 93] Compiling LLVM.General.Internal.FFI.Cleanup ( src/LLVM/General/Internal/FFI/Cleanup.hs, dist/build/LLVM/General/Internal/FFI/Cleanup.o ) [35 of 93] Compiling LLVM.General.Internal.FFI.Constant ( src/LLVM/General/Internal/FFI/Constant.hs, dist/build/LLVM/General/Internal/FFI/Constant.o ) ghc: internal error: stg_ap_pv_ret (GHC version 7.10.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: llvm-general-3.5.1.2 failed during the building phase. The exception was: ExitFailure (-6) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11764> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9046: Panic in GHCi when using :print
by GHC 29 Jun '18

29 Jun '18

#9046: Panic in GHCi when using :print ------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: GHCi | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When using names generated by :print, GHCi panics sometimes. According to #ghc, this is reproducible on ''x86_64-apple-darwin'' as well, but is not an issue in ''7.6.3 x86_64 linux''. {{{ > let a = [1] > :print a a = (_t1::Num t => [t]) > :t _t1 ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): tcTyVarDetails t{tv avD} [tv] > _t1 <same panic> }}} From playing around with it a bit, this seems to have something to do with polymorphic values. {{{ -- No panic > let a = [1 :: Int] > let a = 1 :: Int > let a = "hello" -- Panic > let a = [1] > let a = 1 > let a = "hello" -- With -XOverloadedStrings }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9046> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10789: Notify user when a kind mismatch holds up a type family reduction
by GHC 28 Jun '18

28 Jun '18

#10789: Notify user when a kind mismatch holds up a type family reduction -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider this contrived example: {{{ {-# LANGUAGE TypeFamilies, PolyKinds, UndecidableInstances #-} module Bug where import Data.Proxy type family F (a :: k) :: k type instance F a = G a type family G a type instance G a = a foo :: Proxy (F Maybe) -> Proxy Maybe foo = id }}} This (correctly) fails to compile. The error message is {{{ Bug.hs:14:7: Couldn't match type ‘F Maybe’ with ‘Maybe’ Expected type: Proxy (F Maybe) -> Proxy Maybe Actual type: Proxy Maybe -> Proxy Maybe In the expression: id In an equation for ‘foo’: foo = id Failed, modules loaded: none. }}} But this is peculiar, but it surely looks like `F` should be a type-level identity function! Of course, upon further inspection, we see that `F` is partial. It reduces only at kind `*`. This is quite hard to figure out, though, especially given that we're using the "default to `*`" behavior of open type families to arrange for this kind restriction. Thus, I propose: figure out when a type family reduction is held up due to a kind mismatch, and inform the user. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10789> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15