July 2018 - ghc-tickets

[GHC] #15343: Implicitly quantifying a kind variable causes GHC 8.6 to panic (coercionKind)
by GHC 31 Jul '18

31 Jul '18

#15343: Implicitly quantifying a kind variable causes GHC 8.6 to panic (coercionKind) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (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 panics on GHC 8.6 and later: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind import Data.Type.Equality data family Sing :: forall k. k -> Type data SomeSing :: Type -> Type where SomeSing :: Sing (a :: k) -> SomeSing k class SingKind k where type Demote k :: Type fromSing :: Sing (a :: k) -> Demote k toSing :: Demote k -> SomeSing k data instance Sing (z :: a :~~: b) where SHRefl :: Sing HRefl instance SingKind (a :~~: b) where type Demote (a :~~: b) = a :~~: b fromSing SHRefl = HRefl toSing HRefl = SomeSing SHRefl data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type infixr 0 ~> type family Apply (f :: k1 ~> k2) (x :: k1) :: k2 (~>:~~:) :: forall (j :: Type) (k :: Type) (a :: j) (b :: k) (p :: forall (z :: Type) (y :: z). (a :~~: y) ~> Type) (r :: a :~~: b). Sing r -> Apply p HRefl -> Apply p r (~>:~~:) SHRefl pHRefl = pHRefl type family Why (a :: j) (e :: a :~~: (y :: z)) :: Type where Why a (_ :: a :~~: y) = y :~~: a data WhySym (a :: j) :: forall (y :: z). (a :~~: y) ~> Type -- data WhySym (a :: j) :: forall z (y :: z). (a :~~: y) ~> Type -- The version above does NOT panic type instance Apply (WhySym a) e = Why a e hsym :: forall (j :: Type) (k :: Type) (a :: j) (b :: k). a :~~: b -> b :~~: a hsym eq = case toSing eq of SomeSing (singEq :: Sing r) -> (~>:~~:) @j @k @a @b @(WhySym a) @r singEq HRefl }}} {{{ $ /opt/ghc/8.6.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.6.0.20180627 for x86_64-unknown-linux): coercionKind Nth:3 (Inst {co_a1jI} (Coh <k_a1js[sk:1]>_N (Nth:0 (Sym {co_a1jI})))) Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/types/Coercion.hs:1887:9 in ghc:Coercion }}} As noted in the comments, replacing `WhySym` with a version that explicitly quantifies `z` avoids the panic. This is a regression from GHC 8.4.3, in which the program simply errored: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:56:38: error: • Expected kind ‘forall z (y :: z). (a1 :~~: y) ~> *’, but ‘WhySym a’ has kind ‘forall (y :: z0). TyFun (a1 :~~: y) * -> *’ • In the type ‘(WhySym a)’ In the expression: (~>:~~:) @j @k @a @b @(WhySym a) @r singEq HRefl In a case alternative: SomeSing (singEq :: Sing r) -> (~>:~~:) @j @k @a @b @(WhySym a) @r singEq HRefl • Relevant bindings include singEq :: Sing a2 (bound at Bug.hs:55:23) eq :: a1 :~~: b (bound at Bug.hs:54:6) hsym :: (a1 :~~: b) -> b :~~: a1 (bound at Bug.hs:54:1) | 56 | (~>:~~:) @j @k @a @b @(WhySym a) @r singEq HRefl | ^^^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15343> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints
by GHC 31 Jul '18

31 Jul '18

#15316: Regarding coherence and implication loops in presence of QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints | Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- First of all this piece of code: {{{#!hs {-# LANGUAGE RankNTypes, QuantifiedConstraints #-} -- NB: disabling these if enabled: {-# LANGUAGE NoUndecidableInstances, NoUndecidableSuperClasses #-} import Data.Proxy class Class a where method :: a subsume :: (Class a => Class b) => Proxy a -> Proxy b -> ((Class a => Class b) => r) -> r subsume _ _ x = x value :: Proxy a -> a value p = subsume p p method }}} This produces a nonterminating `value` even though nothing warranting recursion was used. Adding: {{{#!hs value' :: Class a => Proxy a -> a value' p = subsume p p method }}} Produces a `value'` that is legitimately equivalent to `method` in that it equals to the value in the dictionary whenever an instance exists (and doesn't typecheck otherwise). Thus two identical expressions in different instance contexts end up having different values (violating coherence?) If we add: {{{#!hs joinSubsume :: Proxy a -> ((Class a => Class a) => r) -> r joinSubsume p x = subsume p p x }}} The fact that this typechecks suggests that GHC is able to infer `Class a => Class a` at will, which doesn't seem wrong. However, the fact that `Class a` is solved from `Class a => Class a` via an infinite loop of implication constraints is questionable. Probably even outright wrong in absence of `UndecidableInstances`. Another issue is the following: {{{#!hs {-# LANGUAGE ConstraintKinds #-} subsume' :: Proxy c -> ((c => c) => r) -> r subsume' _ x = x }}} {{{ • Reduction stack overflow; size = 201 When simplifying the following type: c Use -freduction-depth=0 to disable this check (any upper bound you could choose might fail unpredictably with minor updates to GHC, so disabling the check is recommended if you're sure that type checking should terminate) • In the type signature: subsume' :: Proxy c -> ((c => c) => r) -> r }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15316> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15063: T3001-2 fails on i386 Linux
by GHC 31 Jul '18

31 Jul '18

#15063: T3001-2 fails on i386 Linux -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Profiling | 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: -------------------------------------+------------------------------------- The `T3001-2` testcase fails on i386/Linux: {{{ Wrong exit code for T3001-2(prof_hb)(expected 0 , actual 134 ) Stderr ( T3001-2 ): T3001-2: internal error: Invalid object in processHeapClosureForDead(): 7 (GHC version 8.5.20180419 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted *** unexpected failure for T3001-2(prof_hb) }}} Closure type 7 is `CONSTR_NOCAF`, which is indeed invalid. Tracking this down will take some debugging. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15063> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls
by GHC 31 Jul '18

31 Jul '18

#14346: 8.2.1 regression: heap corruption after safe foreign calls -------------------------------------+------------------------------------- Reporter: andrewchen | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Runtime | Version: 8.2.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Test case: (compile with ghc 8.2.1 and -threaded option) {{{#!haskell module Main where import Control.Concurrent import Control.Monad import Data.Word import Foreign.Marshal.Alloc import Foreign.Ptr import Foreign.Storable foreign import ccall safe "test" c_test :: Ptr Word32 -> IO () main :: IO () main = do replicateM_ 1000 $ threadDelay 1000 _ <- forkIO $ forever $ threadDelay 100 allocaBytes 4 $ \p -> forever $ do c_test p x <- peek p unless (x == 0xDEADBEEF) $ putStrLn "value mismatch" }}} {{{#!c void test(unsigned int *buf) { *buf = 0xDEADBEEF; } }}} On my machine, it detects a few value mismatches before crashing with sigsegv. {{{ $ time ./.stack-work/install/x86_64-linux- nopie/nightly-2017-10-10/8.2.1/bin/bug value mismatch value mismatch value mismatch value mismatch zsh: segmentation fault (core dumped) ./.stack-work/install/x86_64-linux- nopie/nightly-2017-10-10/8.2.1/bin/bug ./.stack-work/install/x86_64-linux-nopie/nightly-2017-10-10/8.2.1/bin/bug 2.11s user 0.25s system 66% cpu 3.543 total }}} I believe this is what is causing crashes in xmobar. See discussion: https://github.com/jaor/xmobar/issues/310. Note that the crash in xmobar still happens without -threaded option, while this example only breaks when compiled with -threaded. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14346> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 41

[GHC] #15402: The settings and behaviour of idle GC are very confusing
by GHC 31 Jul '18

31 Jul '18

#15402: The settings and behaviour of idle GC are very confusing -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime | Version: 8.4.3 System | 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: -------------------------------------+------------------------------------- This extracting the issue between comments * https://ghc.haskell.org/trac/ghc/ticket/13497#comment:3 and * https://ghc.haskell.org/trac/ghc/ticket/13497#comment:14 into their own issue. There are a few problems problems (as of GHC 8.4.3): **1) You can't disable idle GC.** * This is contrary to the [https://downloads.haskell.org/~ghc/8.4.3/docs/html/users_guide/runtime_cont… #rts-flag--I%20%E2%9F%A8seconds%E2%9F%A9 manual], which says `Specifying -I0 disables the idle GC.`. * Passing `+RTS -I0` will run the idle GC a few times and then it will stop. [https://ghc.haskell.org/trac/ghc/ticket/13497#comment:10 Detailed here]. * It will run in intervals of `0.3` seconds (which is claimed to be the default for `-I` in the manual). **2) Giving the default for `+RTS -I` explicitly, namely `+RTS -I0.3`, changes the behaviour.** * With it given, idle GC will run every 0.3 seconds. * With it not given, it will run for a few times at 0.3 second and then stop. * This is exactly the behaviour of `-I0`. So if the manual said "the default for `-I` is `-I0`, that would be (perversely) more accurate. **3) The docs suggest idle GC is only in effect with `-threaded`.** * [https://downloads.haskell.org/~ghc/8.4.3/docs/html/users_guide/runtime_cont… #rts-flag--I%20%E2%9F%A8seconds%E2%9F%A9 manual "In the threaded and SMP versions of the RTS (see -threaded ...)."] * But idle GC settings like `+RTS -I` clearly also affect the nonthreaded RTS. **4) The concept of running the idle GC "for a little while" is a bit dubious in my opinion.** * Its [https://ghc.haskell.org/trac/ghc/ticket/13497#comment:13 origin as a power-saving mechanism] is sensible. * But it makes things "weird": When you look at `strace`, then first there's `SIGVTALRM` going on (because the idle GC timer of 0.3 seconds is checked against in each timer signal tick of 0.02 seconds by default), then after some time they suddenly stop. Of course `SIGVTALRM` occurring can also have effects on underlying library calls (syscalls return with `EINTR`), so (at least in non`-threaded`) a simple idling Haskell program creates some time-dependent behaviour on C libraries being used. * This makes debugging signal issues and behaviour extra hard, if you constantly have to keep in mind "oh but in the next 0.3 seconds the program will behave like this, and then behaviour will change. When you're debugging with `strace`, you have to be constantly aware whether or not the current output you read is inside or outside that time window. * But I don't have an idea of how this could be improved without sacrificing something else, so I guess this point just remains as "weird" for now. ---- I think points 1-3 are fixable, we should perhaps * make `-I<thedefaultvalue>` behave the same as not giving `-I` * change the "default value" to something that reflects what the current default behaviour actually is * the actual possibilities for this option expressed in Haskell would be `data IdleGcMode = NoneAtAll | StoppingAfterSeconds Double | IntervalSeconds Double` * so perhaps we should change `-I` to allow passing the following values to it: * `-I<seconds>`, e.g. `-I0.3` to mean `IntervalSeconds 0.3` * `-I<seconds>stopping`, e.g. `-I0.3stopping` to mean `StoppingAfterSeconds 0.3` * `-I0` to mean `NoneAtAll` * and the default would be `-I0.3stopping` to reflect the current default. * fix the documentation to reflect all this -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15402> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12030: GHCi Proposal: Display (Data.Kind.)Type instead of *
by GHC 31 Jul '18

31 Jul '18

#12030: GHCi Proposal: Display (Data.Kind.)Type instead of * -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.1 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: -------------------------------------+------------------------------------- This is premature but what the darn, {{{ >>> :kind Maybe Maybe :: Type -> Type >>> :kind StateT StateT :: Type -> (Type -> Type) -> Type -> Type >>> :kind Eq Eq :: Type -> Constraint >>> :info Functor class Functor (f :: Type -> Type) where ... }}} `*` throws students off and makes it seem scarier than it is. Symbols are harder to search for in general and to understand without documentation, `Type` on the other hand is descriptive. There are valid arguments against displaying `Type`: 1. It's a recent feature subject to change. 2. Although symbols are more difficult to search for, `*` is established in educational materials, logs, blogs and questions. 3. By default `Type` is not in scope so a user cannot ask for information in GHCi. `*` is established and searching for “Haskell asterisk” yields a lot resources but [https://support.google.com/websearch/answer/2466433?hl=en ‘*’ is also a wildcard] in Google and ignored by GitHub. With time `Type` would be a good search term but currently it's chicken-and-the-egg. Previous versions of GHCi error on `:kind *` and `:info *` only shows multiplication so that wouldn't be a huge difference but we can qualify by default: {{{ >>> :kind Maybe Maybe :: Data.Kind.Type -> Data.Kind.Type >>> :kind StateT StateT :: Data.Kind.Type -> (Data.Kind.Type -> Data.Kind.Type) -> Data.Kind.Type -> Data.Kind.Type >>> :kind Eq Eq :: Data.Kind.Type -> Constraint >>> :info Functor class Functor (f :: Data.Kind.Type -> Data.Kind.Type) where ... }}} or display `*` normally and only when `TypeInType` is set do we display `Type`. I don't love it (and love `GHC.Types.Type` slightly less) but there is a precedent for unqualified names, browsing the Prelude for example: {{{#!hs ($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r). (a -> b) -> a -> b undefined :: forall (r :: GHC.Types.RuntimeRep) (a :: TYPE r). GHC.Stack.Types.HasCallStack => a }}} __If__ the consensus is that this will happen sometime down the line consider that each passing release means many more books and blog posts get written using `*`. I wasn't planning on resulting to scare tactics but [https://www.peoria.com/spaw/spawimages/members/member60763/shoot_this_dog.j… here we are]... ---- If needed a migration plan can be drafted like the Semigroup/FTP/AMP/BBP/MonadFail/expanding Float/... proposals, possibly culminating in `Type` fully replacing `*` and being imported by default. I'm sure there are some further reaching consequences to this and better arguments against. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12030> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15459: Wredundant-constraints does not work when constraint synonym is used
by GHC 31 Jul '18

31 Jul '18

#15459: Wredundant-constraints does not work when constraint synonym is used -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 ConstraintKinds #-} {-# OPTIONS_GHC -Wredundant-constraints #-} module Main where import Data.List main :: IO () main = return () withWarning :: (Show a, Ord a) => [a] -> [a] withWarning = sort type ConstraintSynonym a = (Show a, Ord a) withoutWarning :: ConstraintSynonym a => [a] -> [a] withoutWarning = sort }}} {{{ Main.hs:12:1: warning: [-Wredundant-constraints] • Redundant constraint: Show a • In the type signature for: withWarning :: forall a. (Show a, Ord a) => [a] -> [a] | 14 | withWarning :: (Show a, Ord a) => [a] -> [a] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} The withoutWarning function does not need the (Show a) constraint but there is no warning for it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15459> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15458: Misleading error message on mising BangPatterns extension
by GHC 31 Jul '18

31 Jul '18

#15458: Misleading error message on mising BangPatterns extension -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Poor/confusing (amd64) | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For following program I'm getting an unexpected error message. {{{#!hs foo :: Int -> Int foo = bar where bar :: Int -> Int bar !i = i }}} {{{ $ ghc -o Test Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Test.hs:4:5: error: The type signature for ‘bar’ lacks an accompanying binding | 4 | bar :: Int -> Int | ^^^ }}} Enabling `-XBangPatterns` fixes the issue but I wanted the compiler to suggest me to enable it: {{{ $ ghc -XBangPatterns -o Test Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Test.hs:1:1: error: The IO action ‘main’ is not defined in module ‘Main’ | 1 | foo :: Int -> Int | ^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15458> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15440: Flush eventlog in hs_init_ghc
by GHC 30 Jul '18

30 Jul '18

#15440: Flush eventlog in hs_init_ghc -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 8.4.3 System | 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: -------------------------------------+------------------------------------- Currently GHC RTS traces some basic information about the process in `hs_init_ghc` but the information is often flushed to the eventlog at the very end of the process lifetime. Or even worse, it's never written to it if the process terminates abnormally. This is very inconvenient because the information contains some useful stuff like EVENT_WALL_CLOCK_TIME, which is quite important if user wants to sync timestamps in the eventlog with clock. The simplest way to fix the issue is to flush the eventlog buffer in `hs_init_ghc`. This is implemented at https://github.com/maoe/ghc/commit/30e20e4e66adccc28c59c8876331918d30eacef2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15440> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15386: TTG typo: XFieldOcc should be XCFieldOcc
by GHC 30 Jul '18

30 Jul '18

#15386: TTG typo: XFieldOcc should be XCFieldOcc -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- In the following {{{#!hs data FieldOcc pass = FieldOcc { extFieldOcc :: XFieldOcc pass , rdrNameFieldOcc :: Located RdrName -- ^ See Note [Located RdrNames] in HsExpr } | XFieldOcc (XXFieldOcc pass) }}} we are using `XFieldOcc` for both the `extFieldOcc` type and the extra constructor. The first one should be `XCFieldOcc`/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15386> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4