February 2019 - ghc-tickets

[GHC] #8685: -split-objs doesn't work for executables
by GHC 08 Mar '19

08 Mar '19

#8685: -split-objs doesn't work for executables ------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- While investigating [this bug report](https://github.com/haskell/cabal/issues/1611), I've noticed that the `-split-objs` option only works for libraries, but not for executables. That is, unlike in the case of libraries, the driver feeds only `A.o B.o ...` files to the linker instead of `A_split_0.o A_split_1.o ... B_split_0.o B_split_1.o ...`. It'd be nice if `-split-objs` could be changed to also work on executables. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8685> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8629: Option 'split-objs' being ignored when trying to reduce object code size in iOS cross-compilation
by GHC 08 Mar '19

08 Mar '19

#8629: Option 'split-objs' being ignored when trying to reduce object code size in iOS cross-compilation ------------------------------------+--------------------------------- Reporter: f1rstmistake | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: ios | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- I have been trying to statically link Pandoc packages to iOS application following the guide in https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS and it's great so far! I have finally successfully use Pandoc library in iOS app, but the binary size is very big! 1. More than 50MB when using Pandoc library. 2. Around 5MB for simple haskell code. I try to add “split-objs: True” in .cabal/config file, but when running cabal I got this message: {{{ Preprocessing library pandoc-1.12.2.1... unused terminals: 1 on the commandline: Warning: ignoring -fsplit-objs }}} And if I ignore that, at the end of build, I get another error message that stop the build. {{{ cabal: dist-i386/build/Text/Pandoc_o_split: does not exist }}} I try with another package and got similar error message. It seems that split-objs not only being ignored by cross-compilation ghc, but will also fail the build. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8629> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15913: ghc-8.6.2 fails to build on s390x (unregisterised): ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’?
by GHC 08 Mar '19

08 Mar '19

#15913: ghc-8.6.2 fails to build on s390x (unregisterised): ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (make) | Keywords: | Operating System: Linux Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc-8.6 fails to build on s390x (likely any unregisterised build with ghc 8.2 or 8.4) apparently due to some mix up of include files between stage0 and stage1 compilers. {{{ "/usr/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -package-db libraries/bootstrapping.conf -this-unit-id ghc-8.6.2 -hide-all-packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/stage1/build -Icompiler/stage1/build -icompiler/stage1/build/./autogen -Icompiler/stage1/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -Icompiler/stage1/build/. -Icompiler/stage1/build/parser -Icompiler/stage1/build/utils -Icompiler/stage1/build/stage1 -optP- include -optPcompiler/stage1/build/./autogen/cabal_macros.h -package-id array-0.5.2.0 -package-id base-4.10.1.0 -package-id binary-0.8.6.0 -package-id bytestring-0.10.8.2 -package-id containers-0.5.10.2 -package- id deepseq-1.4.3.0 -package-id directory-1.3.0.2 -package-id filepath-1.4.1.2 -package-id ghc-boot-8.6.2 -package-id ghc-boot-th-8.6.2 -package-id ghc-heap-8.6.2 -package-id ghci-8.6.2 -package-id hpc-0.6.0.3 -package-id process-1.6.1.0 -package-id template-haskell-2.14.0.0 -package-id terminfo-0.4.1.2 -package-id time-1.8.0.2 -package-id transformers-0.5.5.0 -package-id unix-2.7.2.2 -Wall -Wno-name-shadowing -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -Wnoncanonical-monoid-instances -this-unit-id ghc -XHaskell2010 -XNoImplicitPrelude -DNO_REGS -DNOSMP -optc-DNOSMP -DSTAGE=1 -Rghc-timing -Wcpp-undef -no-user-package-db -rtsopts -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -c compiler/utils/Binary.hs -o compiler/stage1/build/Binary.o /tmp/ghc24ef_0/ghc_3.hc: In function ‘cNqW_entry’: /tmp/ghc24ef_0/ghc_3.hc:50988:61: error: error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? ((struct {W_ x;} __attribute__((packed))*) _sHcZ)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ stg_MUT_ARR_PTRS_FROZEN_DIRTY_info | 50988 | ((struct {W_ x;} __attribute__((packed))*) _sHcZ)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; | ^ /tmp/ghc24ef_0/ghc_3.hc:50988:61: error: note: each undeclared identifier is reported only once for each function it appears in | 50988 | ((struct {W_ x;} __attribute__((packed))*) _sHcZ)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; | ^ /tmp/ghc24ef_0/ghc_3.hc: In function ‘cNra_entry’: /tmp/ghc24ef_0/ghc_3.hc:51045:61: error: error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? ((struct {W_ x;} __attribute__((packed))*) _sHcZ)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ stg_MUT_ARR_PTRS_FROZEN_DIRTY_info | 51045 | ((struct {W_ x;} __attribute__((packed))*) _sHcZ)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; | ^ /tmp/ghc24ef_0/ghc_3.hc: In function ‘sHDG_entry’: /tmp/ghc24ef_0/ghc_3.hc:56499:61: error: error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? ((struct {W_ x;} __attribute__((packed))*) _sHDE)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ stg_MUT_ARR_PTRS_FROZEN_DIRTY_info | 56499 | ((struct {W_ x;} __attribute__((packed))*) _sHDE)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; | ^ /tmp/ghc24ef_0/ghc_3.hc: In function ‘cO9A_entry’: /tmp/ghc24ef_0/ghc_3.hc:56819:61: error: error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? ((struct {W_ x;} __attribute__((packed))*) _sHDE)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ stg_MUT_ARR_PTRS_FROZEN_DIRTY_info | 56819 | ((struct {W_ x;} __attribute__((packed))*) _sHDE)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; | ^ /tmp/ghc24ef_0/ghc_3.hc: In function ‘cOa5_entry’: /tmp/ghc24ef_0/ghc_3.hc:56907:61: error: error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? ((struct {W_ x;} __attribute__((packed))*) _sHDE)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ stg_MUT_ARR_PTRS_FROZEN_DIRTY_info | 56907 | ((struct {W_ x;} __attribute__((packed))*) _sHDE)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; | ^ `gcc' failed in phase `C Compiler'. (Exit code: 1) <<ghc: 5594223368 bytes, 548 GCs, 37786228/65761936 avg/max bytes residency (14 samples), 177M in use, 0.001 INIT (0.001 elapsed), 6.007 MUT (6.639 elapsed), 2.510 GC (2.514 elapsed) :ghc>> make[1]: *** [compiler/ghc.mk:446: compiler/stage1/build/Binary.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:125: all] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15913> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8095: TypeFamilies painfully slow
by GHC 08 Mar '19

08 Mar '19

#8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time Architecture: Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 5321 | -------------------------------------+------------------------------------- I'm using the TypeFamilies extension to generate types that are quite large. GHC can handle these large types fine when they are created manually, but when type families get involved, GHC's performance dies. Unlike in ticket #5321, using tail recursion does not eliminate the problem, and the order of arguments greatly affects compile time. I've attached a file Types.hs that demonstrates the problems. This file generates another Haskell file which has the problems. It takes 3 flags. The first is the size of the type to generate, the second is which type family function to use, and the third is whether to call the type family or just use a manually generated type. Here are my performance results: Using non-tail recursion, I get these results. I have to increase the stack size based on the size of the type I want to generate. {{{ $ ./Types 200 a a > test.hs && time ghc test.hs > /dev/null -fcontext- stack=250 real 0m2.973s $ ./Types 300 a a > test.hs && time ghc test.hs > /dev/null -fcontext- stack=350 real 0m6.018s $ ./Types 400 a a > test.hs && time ghc test.hs > /dev/null -fcontext- stack=450 real 0m9.995s $ ./Types 500 a a > test.hs && time ghc test.hs > /dev/null -fcontext- stack=550 real 0m15.645s }}} Tail recursion generates much slower compile times for some reason, and I still need to adjust the stack size: {{{ $ ./Types 200 b a > test.hs && time ghc test.hs > /dev/null -fcontext- stack=250 real 0m16.120s }}} Changing the order of arguments to the recursive type family greatly changes the run times: {{{ $ ./Types 200 c a > test.hs && time ghc test.hs > /dev/null -fcontext- stack=250 real 0m6.095s }}} Without the type family, I get MUCH better performance: {{{ $ ./Types 10000 a d > test.hs && time ghc test.hs > /dev/null real 0m2.271s }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8095> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 64

[GHC] #16365: Inconsistency in quantified constraint solving
by GHC 08 Mar '19

08 Mar '19

#16365: Inconsistency in quantified constraint solving -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following program: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Data.Kind import Data.Proxy class C a where m :: a -> () data Dict c = c => Dict ----- type family F a :: Type -> Type class C (F a b) => CF a b instance C (F a b) => CF a b works1 :: (forall z. CF a z) => Proxy (a, b) -> Dict (CF a b) works1 _ = Dict works2 :: ( CF a b) => Proxy (a, b) -> Dict (C (F a b)) works2 _ = Dict works3, fails :: (forall z. CF a z) => Proxy (a, b) -> Dict (C (F a b)) works3 p | Dict <- works1 p = Dict fails _ = Dict }}} `fails`, as its name suggests, fails to typecheck: {{{ $ /opt/ghc/8.6.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:33:11: error: • Could not deduce (C (F a b)) arising from a use of ‘Dict’ from the context: forall z. CF a z bound by the type signature for: fails :: forall a b. (forall z. CF a z) => Proxy (a, b) -> Dict (C (F a b)) at Bug.hs:31:1-71 • In the expression: Dict In an equation for ‘fails’: fails _ = Dict | 33 | fails _ = Dict | ^^^^ }}} But I see no reason why this shouldn't typecheck. After all, the fact that `works1` typechecks proves that GHC's constraint solver is perfectly capable of deducing that `(forall z. CF a z)` implies `(CF a b)`, and the fact that `works2` typechecks proves that GHC's constraint solver is perfectly capable of deducing that `(CF a b)` implies that `(C (F a b))`. Why then can GHC's constraint solver not connect the dots and deduce that `(forall z. CF a z)` implies `(C (F a b))` (in the type of `fails`)? Note that something with the type `(forall z. CF a z) => Proxy (a, b) -> Dict (C (F a b))` //can// be made to work if you explicitly guide GHC along with explicit pattern-matching on a `Dict`, as `works3` demonstrates. But I claim that this shouldn't be necessary. Moreover, in this variation of the program above: {{{#!hs -- <as above> ----- data G a :: Type -> Type class C (G a b) => CG a b instance C (G a b) => CG a b works1' :: (forall z. CG a z) => Proxy (a, b) -> Dict (CG a b) works1' _ = Dict works2' :: ( CG a b) => Proxy (a, b) -> Dict (C (G a b)) works2' _ = Dict works3' :: (forall z. CG a z) => Proxy (a, b) -> Dict (C (G a b)) works3' _ = Dict }}} `works3'` needs no explicit `Dict` pattern-matching to typecheck. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16365> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #16342: Kind inference crash
by GHC 08 Mar '19

08 Mar '19

#16342: Kind inference crash -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- Here's a gnarly test case {{{ {-# LANGUAGE MultiParamTypeClasses, TypeInType, ConstrainedClassMethods, ScopedTypeVariables #-} module Foo where import Data.Proxy class C (a::ka) x where cop :: D a x => x -> Proxy a -> Proxy a cop _ x = x :: Proxy (a::ka) class D (b::kb) y where dop :: C b y => y -> Proxy b -> Proxy b dop _ x = x :: Proxy (b::kb) }}} This crashes every recent GHC with {{{ • GHC internal error: ‘kb’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [avu :-> Type variable ‘b’ = b :: ka, avv :-> Type variable ‘y’ = y :: *, avw :-> Identifier[x::Proxy b, NotLetBound], avx :-> Type variable ‘ka’ = ka :: *] • In the kind ‘kb’ In the first argument of ‘Proxy’, namely ‘(b :: kb)’ In an expression type signature: Proxy (b :: kb) | 13 | dop _ x = x :: Proxy (b::kb) | ^^ }}} Yikes. Reason: * `C` and `D` are mutually recursive * `ka` and `kb` get bound to unification variables, and then get unified in the kind-inference phase * As a result the utterly-final class for `C` and `D` end up with the same `TyVar` for `ka`/`kb`. * And then, for one of them, the tyvar is not in scope when (much, much later) we check the default declaration. Gah! In `generaliseTcTyCon` I think we may need to do a reverse-map to ensure that each of the final `tyConTyVars` has the `Name` from this declaration, rather than accidentally getting a `Name` from another decl in the mutually recursive group. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16342> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #16221: Core Lint error with a data type
by GHC 08 Mar '19

08 Mar '19

#16221: Core Lint error with a data type -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 (Type checker) | 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: -------------------------------------+------------------------------------- The following data declaration fails `-dcore-lint` {{{ #!haskell {-# LANGUAGE PolyKinds, ExplicitForAll, ExistentialQuantification #-} module T16221 where data T0 a = forall k (b :: k). MkT0 (T0 b) !Int }}} The test case was extracted from T14066a, the bang is to force the data type to have a wrapper. This has been present at least since GHC 8.0. {{{ <no location info>: warning: In the type ‘T0 a_a1wY’ Kind application error in type ‘T0 a_a1wY’ Function kind = forall k. k -> * Arg kinds = [(k_X1x2, *), (a_a1wY, k_a1wZ)] Fun: k_X1x2 (a_a1wY, k_a1wZ) <no location info>: warning: In the expression: MkT0 @ k_X1x2 @ a_a1wY @ k_X1x2 @ b_a1x0 dt_a1xC dt_X1xK Kinds don't match in type application: Type variable: a_X1xw :: k_X1x2 Arg type: a_a1wY :: k_a1wZ Linted Arg kind: k_a1wZ <no location info>: warning: In the type ‘T0 a_a1wY’ Kind application error in type ‘T0 a_a1wY’ Function kind = forall k. k -> * Arg kinds = [(k_X1x2, *), (a_a1wY, k_a1wZ)] Fun: k_X1x2 (a_a1wY, k_a1wZ) <no location info>: warning: In the expression: MkT0 @ k_X1x2 @ a_a1wY @ k_X1x2 @ b_a1x0 dt_a1xC dt_X1xK Kinds don't match in type application: Type variable: a_X1xw :: k_X1x2 Arg type: a_a1wY :: k_a1wZ Linted Arg kind: k_a1wZ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16221> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #16263: GHC accepts illegal constraint in kind
by GHC 08 Mar '19

08 Mar '19

#16263: GHC accepts illegal constraint in kind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.6 accepts {{{#!hs data Q :: Eq a => Type }}} It shouldn't, as we can't have `Eq a` as a constraint in kinds. Note that writing a constructor for `Q` is rejected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16263> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #11715: There's something fishy going on with Constraint
by GHC 07 Mar '19

07 Mar '19

#11715: There's something fishy going on with Constraint -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 (Type checker) | 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 first noticed something was a bit odd with `Constraint` when chasing #11334. Consider this testcase, {{{#!hs import Data.Typeable main = do print $ typeRep (Proxy :: Proxy Eq) print $ typeOf (Proxy :: Proxy Eq) }}} With `ghc-8.0` this will produce, {{{ Eq Proxy (* -> *) Eq }}} Notice the second line; GHC seems to be claiming that `Eq :: * -> *`, which is clearly nonsense. I believe this issue may be the cause of some of the testsuite failures that I'm seeing on #11011. Unfortunately I haven't the foggiest where this issue might originate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11715> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 82

[GHC] #15918: GHC panic from TypeApplications(?)
by GHC 07 Mar '19

07 Mar '19

#15918: GHC panic from TypeApplications(?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Minimized from https://gist.github.com/Icelandjack/683bd4b79027695ffc31632645c9d58b, I don't expect `Build []` to kind check but ti shouldn't crash. {{{#!hs {-# Language PolyKinds #-} {-# Language TypeFamilies #-} {-# Language ConstraintKinds #-} {-# Language FlexibleContexts #-} {-# Language QuantifiedConstraints #-} {-# Language UndecidableInstances #-} import Data.Kind class Rev f where rev :: f a instance (forall xx. cls xx => Rev xx) => Rev (Build cls) where rev = undefined data Build :: ((k -> Type) -> Constraint) -> (k -> Type) uu = rev :: Build [] a }}} gives a panic {{{ $ ghc-stage2 --interactive -ignore-dot-ghci ~/hs/711_bug.hs GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( ~/hs/711_bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181029 for x86_64-unknown-linux): ASSERT failed! irred_a1zW :: [(xx_a1zV[sk:3] |> Sym {co_a1zu})] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:1826:53 in ghc:TcType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15918> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19