- ghc-tickets - Haskell.org

Re: [GHC] #5622: Out of memory in such a simple case
by GHC 08 Jan '19

08 Jan '19

#5622: Out of memory in such a simple case -------------------------------------+------------------------------------- Reporter: quux | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.2.1 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kirelagin): For all those people from the future who’ll try to figure out what is going on here, a small clarification: the issue is not with type-inference itself, you can easily use `:t` in GHCi and it will infer the type instantly. The problem is that in Core type applications are spelled out explicitly, so the ''terms'' end up being exponentially large. {{{ foo4 :: forall a_alK. a_alK -> a_alK [GblId, Str=DmdType] foo4 = \ (@ a_am0) -> id @ (((a_am0 -> a_am0) -> a_am0 -> a_am0) -> (a_am0 -> a_am0) -> a_am0 -> a_am0) (id @ ((a_am0 -> a_am0) -> a_am0 -> a_am0)) (id @ (a_am0 -> a_am0)) (id @ a_am0) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5622#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16148: Better type inference for Constraint vs Type
by GHC 08 Jan '19

08 Jan '19

#16148: Better type inference for Constraint vs Type -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- An enduring infelicity in GHC’s type inference is the treatment of tuples. Consider, this from `RaeJobTalk`: {{{ type family F c sch where F _ '[] = (() :: Constraint) F c (col ': cols) = (c Int, F c cols) }}} When kind-checking `F`, we initially give it a return kind of kappa, a unification variable. Suppose we kind-check the second equation first. Then what kind of tuple is it, a constraint tuple, or an ordinary type tuple. We must unify kappa with `Type` or `Constraint` respectively – and they are different kinds. How can we choose which? Currently we have the following unsatisfactory ruse: 1. Look at the “expected kind”. If we kind-check the second equation first we learn nothing from that 2. Infer kinds for all of the elements of the type. Again in this case we learn nothing. 3. If we still know nothing, arbitrarily pick Type This is horrible. If we kind check the first equation first, step 1 will discover Constraint, and kind checking succeeds. But if we put the equations in the other order, kind checking fails. Ugh! Another example with exactly the same cause is #16139. What to do? I can only think of three approaches: A. Add a pseudo constraint `(TC kappa)` meaning “kappa must eventually turn out to be either `Type` or `Constraint`”. When generalising, default to `Type`. B. Same, but by having a special sort of TauTv, a TCTv, which can only unify with Type or Constraint. Again, do not generalise over such type variables. C. Define {{{ type Type = TYPE (LiftedRep T) type Constraint = TYPE (LiftedRep C) }}} So now we can unify `kappa` with `(TYPE (LiftedRep zeta))` where `zeta` is a unification variable that we must eventually unify with `T` or `C`. Of these, (C) seems most principled, but somehow over-elaborate for our purposes. And the others also seem to be rather too much work to solve a simple, local problem. ------------- For reference, here are the current kinding rules {{{ t1 : TYPE rep1 t2 : TYPE rep2 (FUN) ---------------- t1 -> t2 : Type t1 : Constraint t2 : TYPE rep (PRED1) ---------------- t1 => t2 : Type t1 : Constraint t2 : Constraint (PRED2) --------------------- t1 => t2 : Constraint ty : TYPE rep `a` is not free in rep (FORALL1) ----------------------- forall a. ty : TYPE rep ty : Constraint (FORALL2) ------------------------- forall a. ty : Constraint }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16148> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16139: GHC confused about type synonym kind with QuantifiedConstraints
by GHC 08 Jan '19

08 Jan '19

#16139: GHC confused about type synonym kind with QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: Ashley | Owner: (none) Yakeley | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE KindSignatures, RankNTypes, ConstraintKinds, QuantifiedConstraints #-} module Bug where import Data.Constraint type E (c :: * -> Constraint) = forall (a :: *). Eq a => c a }}} {{{ Bug.hs:5:58: error: • Expected a type, but ‘c a’ has kind ‘Constraint’ • In the type ‘forall (a :: *). Eq a => c a’ In the type declaration for ‘E’ | 5 | type E (c :: * -> Constraint) = forall (a :: *). Eq a => c a | ^^^ }}} Note that GHC accepts the program when the `Eq a` constraint is removed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16139> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14677: Code generator does not correctly tag a pointer
by GHC 08 Jan '19

08 Jan '19

#14677: Code generator does not correctly tag a pointer -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Consider {{{ data T a = MkT ![a] }}} The pointer stored in a `MkT` constructor should always be correctly tagged, never tagged with un-evaluated 00. C.f. [wiki:Commentary/Rts/HaskellExecution/PointerTagging] But this invariant is broken. Example taken from #14626, comment:37-39. Trac14626_1.hs {{{ module Trac14626_1 where data Style = UserStyle Int | PprDebug data SDC = SDC !Style !Int defaultUserStyle :: Bool -> Style defaultUserStyle True = UserStyle 123 defaultUserStyle False = PprDebug }}} Trac14626_2.hs {{{ module Trac14626_2 where import Trac14626_1 f :: Int -> SDC f x = SDC (defaultUserStyle (x > 1)) x }}} Compiling with `ghc Trac14626_1 Trac14626_2 -ddump-simpl -O` results in a similar scenario than the one described by Heisenbug: {{{ -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} defaultUserStyle2 defaultUserStyle2 = I# 123# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} defaultUserStyle1 defaultUserStyle1 = UserStyle defaultUserStyle2 -- RHS size: {terms: 7, types: 2, coercions: 0, joins: 0/0} defaultUserStyle defaultUserStyle = \ ds_dZ7 -> case ds_dZ7 of { False -> PprDebug; True -> defaultUserStyle1 } }}} Our `UserStyle 123` constant has been lifted to top-level, just like in Heisenbugs example. Now looking at the Core of `f` {{{ f f = \ x_a1dk -> case x_a1dk of { I# x1_a2gV -> case ># x1_a2gV 1# of { __DEFAULT -> SDC PprDebug x1_a2gV; 1# -> SDC defaultUserStyle1 x1_a2gV } } }}} (Note how `f` doesn't scrutinise defaultUserStyle1) Looking at the CMM for `f` we can see {{{ ... if (%MO_S_Le_W64(_s2hT::I64, 1)) goto c2ip; else goto c2is; c2ip: I64[Hp - 16] = SDC_con_info; P64[Hp - 8] = PprDebug_closure+2; I64[Hp] = _s2hT::I64; R1 = Hp - 15; Sp = Sp + 8; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; c2is: I64[Hp - 16] = SDC_con_info; P64[Hp - 8] = defaultUserStyle1_closure; -- defaultUserStyle1 isn't tagged! I64[Hp] = _s2hT::I64; R1 = Hp - 15; Sp = Sp + 8; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; }}} When generating code for f the code generator wants to know the `LambdaFormInfo` (the closure type) of `defaultUserStyle1`. Since `defaultUserStyle1` is defined in another module we end up calling `mkLFImported` in `StgCmmClosure` which ultimatively gives an `LFUnknown` which always gets a `DynTag` 0 from `lfDynTag`. I think we lack a bit of information here to give defaultUserStyle1 the correct `LFCon` lambda form. Maybe top-level binders should know its `LambdaForm` and include them in their interfaces. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14677> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1
by GHC 08 Jan '19

08 Jan '19

#13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 (Type checker) | Keywords: | Operating System: Unknown/Multiple ConstraintKinds, KindSignatures | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The attached module compiles without errors with GHC 8.0.1 but needs an explicit kind signature with GHC 8.2.1-rc2. Mentioned in this [https://mail.haskell.org/pipermail/ghc- devs/2017-May/014222.html ghc-dev thread]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13742> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #11621: GHC doesn't see () as a Constraint in type family
by GHC 08 Jan '19

08 Jan '19

#11621: GHC doesn't see () as a Constraint in type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE DataKinds, TypeOperators, KindSignatures, MultiParamTypeClasses, TypeFamilies #-} import Data.Kind class NotFound type family F b where F 'False = (NotFound :: Constraint) F 'True = (() :: Constraint) }}} works fine. Removing all constraints and final line it works without any annotations and infers the type of `F :: Bool -> Constraint`: {{{#!hs type family F b where F 'False = NotFound }}} GHC seems determined that `() :: Type` unless explicitly told otherwise, I would like to be able to write: {{{#!hs type family F b where F 'False = NotFound F 'True = () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11621> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #16135: Panic with ExistentialQuantification and ApplicativeDo
by GHC 08 Jan '19

08 Jan '19

#16135: Panic with ExistentialQuantification and ApplicativeDo -------------------------------------+------------------------------------- Reporter: Ashley | Owner: (none) Yakeley | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE ExistentialQuantification, ApplicativeDo #-} module Bug where data T f = forall a. MkT (f a) runf :: forall f. Functor f => IO (T f) runf = do return () MkT fa <- runf return $ MkT fa }}} {{{ Bug.hs:11:18: error:ghc: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-unknown-linux): No skolem info: [a_a1nb[ssk:2]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcErrors.hs:2891:5 in ghc:TcErrors Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16135> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16057: GHC 8.6.3 hangs with Template Haskell on Windows 10
by GHC 07 Jan '19

07 Jan '19

#16057: GHC 8.6.3 hangs with Template Haskell on Windows 10 -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.6.3 Haskell | Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Have these two files in a directory: Main.hs: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Main where import Helper main = return () test }}} Helper.hs: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Helper where import Language.Haskell.TH test :: Q [Dec] test = return [] }}} If compiled with `ghc Main.hs`, the compilation freezes, when it reaches `Main`. This works well on Linux (Ubuntu 18) using GHC 8.6.3, and there is no problem in GHC 8.4.3 on either Windows or Linux. GCC version: 8.2.0 Rev3 (from MSYS2) / 7.2.0 Rev1 (from cmd.exe) Adding -dcore-lint does not change the outcome. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16057> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #14331: Overzealous free-floating kind check causes deriving clause to be rejected
by GHC 07 Jan '19

07 Jan '19

#14331: Overzealous free-floating kind check causes deriving clause to be rejected -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: deriving | 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 rejects this program: {{{#!hs {-# LANGUAGE DeriveAnyClass #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE PolyKinds #-} module Bug where class C a b data D = D deriving (C (a :: k)) }}} {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:8:1: error: Kind variable ‘k’ is implicitly bound in datatype ‘D’, but does not appear as the kind of any of its type variables. Perhaps you meant to bind it (with TypeInType) explicitly somewhere? | 8 | data D = D deriving (C (a :: k)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} But it really shouldn't, since it's quite possible to write the code that is should generate: {{{#!hs instance C (a :: k) D }}} Curiously, this does not appear to happen for data family instances, as this typechecks: {{{#!hs {-# LANGUAGE DeriveAnyClass #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Bug where class C a b data family D1 data instance D1 = D1 deriving (C (a :: k)) class E where data D2 instance E where data D2 = D2 deriving (C (a :: k)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14331> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 64

[GHC] #15956: Linker error buidling `runghc`
by GHC 07 Jan '19

07 Jan '19

#15956: Linker error buidling `runghc` -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (Hadrian) | 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 on MacOS trying to build `master`. Hadrian fails where `make` succeeds. I'm not doing anything fancy either.. {{{ ghc$ git rev-parse HEAD df570d920fa66db631f936fa377e598fe92bd2a1 ghc$ ./boot && ./configure ghc$ make -j V=0 # succeeds ghc$ ./hadrian/build.sh -c --build-root="_build2" > out.log 2> err.log # fails }}} Hadrian fails when trying to link `runghc`: {{{ Error when running Shake build system: at src/Rules.hs:(34,19)-(47,17): at src/Rules.hs:47:5-17: * Depends on: _build2/stage1/bin/runghc * Raised the exception: user error (Development.Shake.cmd, system command failed Command: _build2/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db _build2/stage1/lib/package.conf.d' '-package-id base-4.12.0.0' '-package- id directory-1.3.3.1' '-package-id filepath-1.4.2.1' '-package-id process-1.6.3.0' '-package-id unix-2.7.2.2' -i -i_build2/stage1/utils/runghc/build -i_build2/stage1/utils/runghc/build/runghc/autogen -iutils/runghc/. -Iincludes -I_build2/generated -I_build2/stage1/utils/runghc/build -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx- ghc-8.7.20181126/process-1.6.3.0/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx- ghc-8.7.20181126/unix-2.7.2.2/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx- ghc-8.7.20181126/time-1.9.2/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx- ghc-8.7.20181126/bytestring-0.10.9.0/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx- ghc-8.7.20181126/base-4.12.0.0/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx- ghc-8.7.20181126/integer-gmp-1.0.2.0/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx- ghc-8.7.20181126/rts-1.0/include -I_build2/generated -optc- I_build2/generated -optP-include -optP_build2/stage1/utils/runghc/build/runghc/autogen/cabal_macros.h -optc-fno-stack-protector -odir _build2/stage1/utils/runghc/build -hidir _build2/stage1/utils/runghc/build -stubdir _build2/stage1/utils/runghc/build -no-auto-link-packages -rtsopts -optl- lgmp -Wnoncanonical-monad-instances -optc-Wno-unknown-pragmas _build2/stage1/utils/runghc/build/Main.o -o _build2/stage1/bin/runghc -O2 -H32m -XHaskell2010 -ghcversion- file=/Users/atheriault/Code/ghc/_build2/generated/ghcversion.h Exit code: 1 Stderr: Undefined symbols for architecture x86_64: "_findPtr", referenced from: -u command line option ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) `gcc' failed in phase `Linker'. (Exit code: 1) ) }}} This must be a recent regression, since I was successfully building with Hadrian as recently as last week. I'll try to bisect, although the failure occurs so late in the compilation pipeline that I expect progress to be quite slow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15956> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7