- ghc-tickets - Haskell.org

[GHC] #16394: GHC internal error while typechecking of instance definition
by GHC 15 Mar '19

15 Mar '19

#16394: GHC internal error while typechecking of instance definition -------------------------------------+------------------------------------- Reporter: Day1721 | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.6.3 (Type checker) | Keywords: | Operating System: Linux Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello. \\ This code won't typecheck because of GHC internal error. {{{#!hs {-# LANGUAGE PolyKinds, TypeFamilies, DataKinds #-} class C a where type T (n :: a) -- v--DIFF--v instance C a => C b => C (a, b) where type T '(n, m) = (T n, T m) }}} with error message: {{{ Bug.hs:7:10: error: • GHC internal error: ‘T’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [a1LS :-> Type variable ‘a’ = a :: *, a1LT :-> Type variable ‘b’ = b :: *] • In the type instance declaration for ‘T’ In the instance declaration for ‘C b => C (a, b)’ | 7 | type T (n, m) = (T n, T m) | ^ Failed, no modules loaded. }}} but this works fine: {{{#!hs {-# LANGUAGE PolyKinds, TypeFamilies, DataKinds #-} class C a where type T (n :: a) -- v--DIFF--v instance (C a, C b) => C (a, b) where type T '(n, m) = (T n, T m) }}} Not sure is a bug, but either way it would be better to make more understandable error message -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16394> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15382: heapprof001 segfaults in prof_hc_hb way on i386
by GHC 13 Mar '19

13 Mar '19

#15382: heapprof001 segfaults in prof_hc_hb way on i386 --------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+------------------------------------- I am seeing the `heapprof001` testcase segmentation fault in the `prof_hc_hb` testsuite way on i386. For instance, https://circleci.com/gh/ghc/ghc/7104. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15382> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #16411: Inconsistent -Wpartial-fields warnings with (~) vs. (~~)
by GHC 13 Mar '19

13 Mar '19

#16411: Inconsistent -Wpartial-fields warnings with (~) vs. (~~) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.4 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: -------------------------------------+------------------------------------- In this program: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -Wpartial-fields #-} module Bug where import Data.Type.Equality data T1 z where MkT1a :: { rec1 :: () } -> T1 Int MkT1b :: (z ~ Bool) => T1 z data T2 z where MkT2a :: { rec2 :: () } -> T2 Int MkT2b :: (z ~~ Bool) => T2 z }}} I get no `-Wpartial-fields`–related warnings for `rec1`, but I do for `rec2`: {{{ GHCi, version 8.6.4: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:13:14: warning: [-Wpartial-fields] Use of partial record field selector: ‘rec2’ | 13 | MkT2a :: { rec2 :: () } -> T2 Int | ^^^^ }}} This feels strangely inconsistent, since if GHC doesn't warn for `rec1`, which uses `(~)`, then I feel like it shouldn't warn for `rec2` either, as the only difference is that the surrounding constructor uses a slightly different equality constraint `(~~)`. The reason this happens is because the `dataConCannotMatch` function has special reasoning for `(~)`, but not `(~~)`. Patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16411> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16347: GHC HEAD regression: piResultTys1
by GHC 12 Mar '19

12 Mar '19

#16347: GHC HEAD regression: piResultTys1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.7 (Type checker) | Keywords: TypeInType | 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 program typechecks on GHC 8.0.2 through 8.6.3, but panics on HEAD: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind import Data.Proxy data T f :: f Type -> Type where MkT :: T f a }}} {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20190219 for x86_64-unknown-linux): piResultTys1 k_a10k[tau:1] [*] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1159:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1063:5 in ghc:Type }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16347> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13951: InScope set assertion failure from monad-skeleton
by GHC 12 Mar '19

12 Mar '19

#13951: InScope set assertion failure from monad-skeleton -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE PolyKinds, GADTs, Rank2Types, ScopedTypeVariables, Trustworthy #-} module Control.Monad.Skeleton.Internal where data Cat k a b where Empty :: Cat k a a Leaf :: k a b -> Cat k a b Tree :: Cat k a b -> Cat k b c -> Cat k a c viewL :: forall k a b r. Cat k a b -> ((a ~ b) => r) -> (forall x. k a x -> Cat k x b -> r) -> r viewL Empty e _ = e viewL (Leaf k) _ r = k `r` Empty viewL (Tree a b) e r = go a b where go :: Cat k a x -> Cat k x b -> r go Empty t = viewL t e r go (Leaf k) t = r k t go (Tree c d) t = go c (Tree d t) }}} Leads to the assertion failure {{{ [1 of 1] Compiling Control.Monad.Skeleton.Internal ( Internal.hs, Internal.o ) WARNING: file compiler/simplCore/OccurAnal.hs, line 2160 Just 3 [] ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170708 for x86_64-unknown-linux): ASSERT failed! in_scope InScope {x_avF ds_d14c} tenv [avF :-> x_avF] tenvFVs [avF :-> x_avF, a11Z :-> k_a11Z] cenv [] cenvFVs [] tys [k1_a120 a_a121 x_avF] cos [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1188:22 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2088:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2121:29 in ghc:TyCoRep substTy, called at compiler/coreSyn/CoreArity.hs:1197:19 in ghc:CoreArity Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1186:5 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2088:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2121:29 in ghc:TyCoRep substTy, called at compiler/coreSyn/CoreArity.hs:1197:19 in ghc:CoreArity Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13951> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11371: Bogus in-scope set in substitutions
by GHC 12 Mar '19

12 Mar '19

#11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Bartosz [https://mail.haskell.org/pipermail/ghc- devs/2016-January/010892.html reports] that substitution isn't working properly for him. He cites this Note in `TyCoRep`: {{{ -- Note [Generating the in-scope set for a substitution] -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- If we want to substitute [a -> ty1, b -> ty2] I used to -- think it was enough to generate an in-scope set that includes -- fv(ty1,ty2). But that's not enough; we really should also take the -- free vars of the type we are substituting into! Example: -- (forall b. (a,b,x)) [a -> List b] -- Then if we use the in-scope set {b}, there is a danger we will rename -- the forall'd variable to 'x' by mistake, getting this: -- (forall x. (List b, x, x)) -- Urk! This means looking at all the calls to mkOpenTCvSubst.... }}} I think this is an outright bug that has been lurking for ages, and which Bartosz has just managed to tickle. Things to do: * We should add an ASSERT to substTy (and similar functions): **when calling `substTy subst ty` it should be the case that the in-scope set in the substitution is a superset of** * **The free vars of the range of the substitution** * **The free vars of ty minus the domain of the substitution** That ASSERT could be added to the immediate callers of `subst_ty` in `TyCoRep`. (Bartosz: if you add that you should find that it trips before the bug you are actually getting.) * How to fix it properly? The places to look are: everywhere that uses (transitively) one of the `mkOpenTCvSubst` or `zipOpenTCvSubst` functions. * Many calls to `mkOpenTCvSubst` produce a substitution that is only applied to closed types; or at least to types whose only free variables are the ones in the domain of the substitution. Example: the call to `zipOpenTCvSubst` in `DataCon.dataConInstSig`. These ones will all satisfy the ASSERT[[BR]][[BR]] * In other cases, we already have the in-scope set in hand. Example: in `CoreLint.lintTyApp` we find a call to `substTyWith`. But Lint carries an in-scope set, so it would be easy to pass it to `substTyWith`.[[BR]][[BR]] * Finally there may be cases where we really have to take the free vars of the type we are substituting into, and add them to the in-scope set. Doubtless all this applies to substituting in coercions too, and indeed into expressions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11371> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 64

[GHC] #16344: GHC infers over-polymorphic kinds
by GHC 11 Mar '19

11 Mar '19

#16344: GHC infers over-polymorphic kinds -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- Consider {{{ data T ka (a::ka) b = MkT (T Type Int Bool) (T (Type -> Type) Maybe Bool) }}} GHC accepts this ''even though it uses polymorphic recursion''. But it shouldn't -- we simply do not have reliable way to infer most general types in the presence of polymorphic recursion. In more detail, in `getInitialKinds`, GHC chooses this (bogus) "monomorphic" kind for T: {{{ T :: forall (ka :: kappa1) -> ak -> kappa2 -> Type }}} where `kappa1` and `kappa1` are unification variables. Then it kind- checks the data constructor declaration, given this mono-kind -- and succeeds! But this is extremely fragile. At call-sites of T we are going to instantiate T's kind. But what if `kappa2` is (somewhere, somehow) late unified wtih `ka`. Then, when instantiating T's kind with `ka := blah`we should get `blah -> blha -> Type`. So how it instantiates will vary depending on what we konw about `kappa2`. No no no. The initial monomorphic kind of T (returned by `getInitialKinds`, and used when checking the recursive RHSs) should be {{{ T :: kappa1 -> kappa2 -> kappa3 -> Type }}} Then indeed this program will be rejected, but so be it. Consider {{{ data T ka (a::ka) b = MkT (T Type Int Bool) (T (Type -> Type) Maybe Bool) }}} GHC accepts this ''even though it uses polymorphic recursion''. But it shouldn't -- we simply do not have reliable way to infer most general types in the presence of polymorphic recursion. In more detail, in `getInitialKinds`, GHC decides this "monomorphic" kind for T: {{{ T :: forall (ka :: kappa1) -> ka -> kappa2 -> Type }}} where `kappa1` and `kappa1` are unification variables. Then it kind- checks the data constructor declaration, given this mono-kind -- and succeeds! But this is extremely fragile. At call-sites of T we are going to instantiate T's kind. But what if `kappa2` is (somewhere, somehow) late unified wtih `ka`. Then, when instantiating T's kind with `ka := blah` we might get `blah -> blah -> Type` or `blah -> kappa2 -> Type`, depending on whether `kappa2 := ka` has happened yet. No no no. The initial monomorphic kind of T (returned by `getInitialKinds`, and used when checking the recursive RHSs) should be {{{ T :: kappa1 -> kappa2 -> kappa3 -> Type }}} Then indeed this program will be rejected, but so be it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16344> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14533: Make GHC more robust against PC crashes by using atomic writes
by GHC 10 Mar '19

10 Mar '19

#14533: Make GHC more robust against PC crashes by using atomic writes -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Yesterday my Windows machine crashed when ghc was building, left me with a lot of corrupted .hi files (and probably .o files as well). That made me think if we should change ghc to write its output with atomic moves. Discussion on `#ghc`: {{{ bgamari: nh2: well, perhaps I'm not sure it's terribly common for compilers to take such precautions though and if we were to do it for interface files then presumably we would also want to do it for object files siarheit_: that would be very nice geekosaur: compilers in general are happy to write out incomplete/garbage object files bgamari: it seems that way nh2: bgamari: right, if we wanted to do it we should do it for all files ghc writes. Possible that other compilers can also write garbage, but maybe ghc can do better -- one less thing the developer has to think about Phyx-: most compilers also don't do the aggressive recompilation avoidance things we do either.. corrupt hi files wouldn't be an issue if the next time it would override them :) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14533> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #16409: fresh install crashes
by GHC 09 Mar '19

09 Mar '19

#16409: fresh install crashes -------------------------------------+------------------------------------- Reporter: eightorbit | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Installing GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A fresh install on windows 10 enterprise using: HaskellPlatform-8.6.3-core-x86_64-setup.exe run as administrator crashes every time I try to start with this error (from powershell): {{{ PS C:\Users\rburgess> ghci -v GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 8.6.3, stage 2 booted by GHC version 8.4.3 Using binary package database: C:\Program Files\Haskell Platform\8.6.3\lib\package.conf.d\package.cache package flags [] loading package database C:\Program Files\Haskell Platform\8.6.3\lib\package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.3 wired-in package integer-gmp mapped to integer-gmp-1.0.2.0 wired-in package base mapped to base-4.12.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.14.0.0 wired-in package ghc mapped to ghc-8.6.3 package flags [] loading package database C:\Program Files\Haskell Platform\8.6.3\lib\package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.3 wired-in package integer-gmp mapped to integer-gmp-1.0.2.0 wired-in package base mapped to base-4.12.0.0 wired-in package rts mapped to rts-1.0 wired-in package template-haskell mapped to template-haskell-2.14.0.0 wired-in package ghc mapped to ghc-8.6.3 *** Parser [source]: !!! Parser [source]: finished in 0.00 milliseconds, allocated 0.184 megabytes *** Desugar: *** Simplify [expr]: !!! Simplify [expr]: finished in 0.00 milliseconds, allocated 0.125 megabytes *** CorePrep [expr]: !!! CorePrep [expr]: finished in 0.00 milliseconds, allocated 1.860 megabytes *** ByteCodeGen [Ghci1]: !!! ByteCodeGen [Ghci1]: finished in 0.00 milliseconds, allocated 0.135 megabytes *** gcc: "C:\Program Files\Haskell Platform\8.6.3\lib\../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "--print-search-dirs" Loading package ghc-prim-0.5.3 ... linking ... ghc.exe: internal error: IMAGE_REL_AMD64_ADDR32[NB]: High bits are set in 1d6004c2659 for ghczmprim_GHCziTypes_ZMZN_closure (GHC version 8.6.3 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} =================================================================== Trying to run ghci and winghci also crashes, but no error. This is a company computer and I don't have admin rights, so I can't try and reinstall very easily. I seem to recall the installation trying to put something in the admin's local directory but we changed this to my local directory. I googled around and only found similar things with compiling. For fun I tried: {{{ PS C:\Users\rburgess> ghci -fexternal-interpreter GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help ghc-iserv: internal error: IMAGE_REL_AMD64_ADDR32[NB]: High bits are set in 24d38172659 for ghczmprim_GHCziTypes_ZMZN_closure (GHC version 8.6.3 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Any help appreciated. It was hard enough to get this approved, I don't want to get some admin back unless a resolution is very likely. I use this as an argument to get them to let me run linux on my computer where I've never had a problem with ghci. :) But if I'm going to sell them on haskell, it would be nice to get it working locally. Let me know if you need other info or try non-admin things. Thanks! --rob -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16409> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16413: GHC bindist with DWARF support seems much slower than non-DWARF
by GHC 09 Mar '19

09 Mar '19

#16413: GHC bindist with DWARF support seems much slower than non-DWARF -------------------------------------+------------------------------------- Reporter: jberryman | 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: -------------------------------------+------------------------------------- Comparing the DWARF and non-DWARF binary distributions, I'm seeing times for a `cabal new-build --disable-profiling --disable-library-profiling all` for a multi-library project showing e.g. 5:46.90 for DWARF, vs 3:56.40 for non-DWARF bindists. I'm assuming this is unexpected since I don't see it proclaimed loudly anywhere. I thought this was irrelevant, but I did try doing `cabal new-build ... --enable-debug-info=0` with the DWARF-supporting GHC but that didn't seem to improve compile time. I don't see anything relevant in my `~/.cabal/config`. Even more confused because I see the same slow timing (~ 5:45) for a `stack build` in the same project, yet it looks like `stack` pulls in a GHC without DWARF-compiled libs: {{{ $ readelf --debug-dump $HOME/.stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/text-1.2.3.1/libHStext-1.2.3.1-ghc8.6.3.so | grep Version $ }}} Maybe `stack` is compiling in a different way though, and the timing similarity is just a coincidence. I first noticed this when building GHC from source. It seemed that uncommenting these caused the regression (though I haven't double- checked): {{{ #GhcLibHcOpts += -g3 #GhcRtsHcOpts += -g3 }}} Attached is the project repo I tested with (again, with `cabal new-clean && cabal new-build --disable-profiling --disable-library-profiling all`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16413> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2