June 2018 - ghc-tickets

[GHC] #15296: Sentence is about Complex type but mentions Simple constructor
by GHC 17 Jul '18

17 Jul '18

#15296: Sentence is about Complex type but mentions Simple constructor -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | 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: -------------------------------------+------------------------------------- There is a mistype in one of the sentences regarding Roles in the documentation : https://ghc.readthedocs.io/en/latest/glasgow_exts.html#nominal- representational-and-phantom {{{ Here are some examples: data Simple a = MkSimple a -- a has role representational type family F type instance F Int = Bool type instance F Age = Char data Complex a = MkComplex (F a) -- a has role nominal data Phant a = MkPhant Bool -- a has role phantom }}} The type Simple has its parameter at role representational, which is generally the most common case. Simple Age would have the same representation as Simple Int. The type Complex, on the other hand, has its parameter at role nominal, because Simple Age and Simple Int are not the same. Lastly, Phant Age and Phant Bool have the same representation, even though Age and Bool are unrelated. The wrong sentence is `The type Complex, on the other hand, has its parameter at role nominal, because Simple Age and Simple Int are not the same. ` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15296> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15007: Don't keep shadowed variables in ghci, both renamer and type checker
by GHC 17 Jul '18

17 Jul '18

#15007: Don't keep shadowed variables in ghci, both renamer and type checker -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: #11547 #14052 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In ticket:14052, we reverted Phab:D2447, then ticket:11547 exists in HEAD again. In ticket:14052#comment:25 and ticket:14052#comment:10, we decide that shadowed variables shouldn't be keep at all. This ticket is created to track the idea. The same error of ticket:11547 was also reported in ticket:14996#comment:2, > {{{#!hs > $ inplace/bin/ghc-stage2 --interactive > GHCi, version 8.5.20180403: http://www.haskell.org/ghc/ :? for help > Prelude> 1 > 1 > Prelude> 1 > 1 > Prelude> _ > > <interactive>:1:1: error: > GHC internal error: ‘Ghci1.it’ is not in scope during type > checking, but it passed the renamer > tcl_env of environment: [] >}}} > > (giving "1" twice is needed to reproduce the error) NB: input "1" twice to create shadowed context is necessary to reproduce this bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15007> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #13775: Type family expansion is too lazy, allows accepting of ill-typed terms
by GHC 17 Jul '18

17 Jul '18

#13775: Type family expansion is too lazy, allows accepting of ill-typed terms -------------------------------------+------------------------------------- Reporter: fizruk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: GHC accepts (amd64) | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm using GHC 8.0.2 and I've just witnessed a weird bug. To reproduce a bug I use this type family, using `TypeError` (this is a minimal type family I could get to keep bug reproducible): {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} import GHC.TypeLits type family Head xs where Head '[] = TypeError (Text "empty list") Head (x ': xs) = x }}} Then I go to GHCi, load this code and observe this: {{{ >>> show (Proxy @ (Head '[])) "Proxy" }}} This looks like a bug to me! I expect `Head '[]` to produce a type error. And indeed it does, if I ask differently: {{{ >>> Proxy @ (Head '[]) <interactive>:9:1: error: • empty list • When checking the inferred type it :: Proxy (TypeError ...) }}} So far it looks like `show` somehow "lazily" evaluates it's argument type and that's why it's possible to `show Proxy` even when `Proxy` is ill- typed. But if I expand `Head '[]` manually then it all works as expected again: {{{ >>> show $ Proxy @ (TypeError (Text "error")) <interactive>:13:8: error: • error • In the second argument of ‘($)’, namely ‘Proxy @(TypeError (Text "error"))’ In the expression: show $ Proxy @(TypeError (Text "error")) In an equation for ‘it’: it = show $ Proxy @(TypeError (Text "error")) }}} You can remove `TypeError` from the original type family: {{{ type family Head xs where Head (x ': xs) = x }}} And it gets even weirder: {{{ >>> show (Proxy @ (Head '[])) "Proxy" >>> Proxy @ (Head '[]) Proxy }}} I did not test this with GHC 8.2. I think this behaviour is not critical for me, but accepting ill-typed terms looks like a bad sign, especially for type-level-heavy programs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13775> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13184: :show bindings broken under -fexternal-interpreter
by GHC 17 Jul '18

17 Jul '18

#13184: :show bindings broken under -fexternal-interpreter -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- This is straight from GHC HEAD: {{{ $ ./inplace/bin/ghc-stage2 --interactive -fexternal-interpreter GHCi, version 8.1.20170123: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/bnitka/.ghc/ghci.conf package flags have changed, resetting and loading new packages... Loaded GHCi configuration from /home/bnitka/.ghci Prelude> let a = 1 Prelude> :show bindings a :: Num p => p = *** Exception: ghc-stage2: this operation requires -fno-external- interpreter Prelude> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13184> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14231: Core lint error "in result of Static argument"
by GHC 17 Jul '18

17 Jul '18

#14231: Core lint error "in result of Static argument" -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Whilst investigating #14211 I encountered a core lint error. {{{ {-# LANGUAGE CPP #-} {-# LANGUAGE RankNTypes #-} module Async where data AsyncT m a = AsyncT { runAsyncT :: forall r. Maybe Int -- state -> m r -- stop -> (a -> Maybe Int -> Maybe (AsyncT m a) -> m r) -- yield -> m r } ------------------------------------------------------------------------------ -- Monad ------------------------------------------------------------------------------ {-# INLINE bindWith #-} bindWith :: (forall c. AsyncT m c -> AsyncT m c -> AsyncT m c) -> AsyncT m a -> (a -> AsyncT m b) -> AsyncT m b bindWith k (AsyncT m) f = AsyncT $ \_ stp yld -> m Nothing stp (\a _ m -> (\x -> (runAsyncT x) Nothing stp yld) $ maybe (f a) (\r -> f a `k` (bindWith k r f)) m ) }}} Compile with `ghc -O2 -fno-worker-wrapper -fstatic-argument-transformation -dcore-lint`. Error: {{{ *** Core Lint errors : in result of Static argument *** <no location info>: warning: In the expression: bindWith @ m_aV5 @ a_aV6 @ b_aV7 k_aSU x_aX3 f_aSW Mismatch in type between binder and occurrence Var: bindWith_rpi Binder type: forall (m1 :: * -> *) a1 b1 . (forall c . AsyncT m_aV5 c -> AsyncT m_aV5 c -> AsyncT m_aV5 c) -> AsyncT m_aV5 a_aV6 -> (a_aV6 -> AsyncT m_aV5 b_aV7) -> AsyncT m_aV5 b_aV7 Occurrence type: forall (m :: * -> *) a b . (forall c . AsyncT m c -> AsyncT m c -> AsyncT m c) -> AsyncT m a -> (a -> AsyncT m b) -> AsyncT m b Before subst: forall (m :: * -> *) a b . (forall c . AsyncT m c -> AsyncT m c -> AsyncT m c) -> AsyncT m a -> (a -> AsyncT m b) -> AsyncT m b *** Offending Program *** }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14231> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #13883: T5435_dyn_asm fails with ld.gold
by GHC 17 Jul '18

17 Jul '18

#13883: T5435_dyn_asm fails with ld.gold -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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 seeing `T5435_dyn_asm` fail with Phab:D3449 using the gold linker. Specifically, {{{ =====> T5435_dyn_asm(normal) 1 of 1 [0, 0, 0] cd "./rts/T5435_dyn_asm.run" && $MAKE -s --no-print-directory T5435_dyn_asm T5435_dyn_asm failed with ['initArray1', 'initArray2', 'ctors2', 'ctors1', 'success'], see all.T for details *** unexpected failure for T5435_dyn_asm(normal) }}} It seems that the ctor list in `T5435_asm.c` is in order `ctors2,ctors1` as it expects that constructors are run in reverse order, yet somehow with gold the constructors are being run in forward order. I've searched high and low for a document specifying this behavior, but the best I can come up with is GCC's [[https://gcc.gnu.org/onlinedocs/gccint/Initialization.html|internals manual]]. I currently don't have a great answer for why gold flips the order. I suspected that the (enabled by default) `--ctors-in-init-array` flag might have something to do with it, but alas that doesn't appear to be the case. Anyways, given that this most certainly isn't GHC's fault and the order requirements aren't well specified anyways, I'm just going to accept the new ordering. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13883> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14057: Upstream Alpine Linux distribution patches
by GHC 16 Jul '18

16 Jul '18

#14057: Upstream Alpine Linux distribution patches -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 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: -------------------------------------+------------------------------------- Alpine Linux has a variety of [[https://git.alpinelinux.org/cgit/aports/tree/community/ghc?h=3.6-stable|pat…]] to allow GHC to build against the musl libc implementation. Let's get these upstream. Here is my take on the patches: * `0000-alpine.patch`: This is a no-brainer. Will gladly accept. * `0000-bootstrap.patch`: I really don't know about this one. The motivation is quite unclear. Needs discussion. * `0001-rm-ghc-pwd.patch`: Already merged in 4c56ad36ee0d1f8b6f1b2bc0d8fff1c9acd1a389. * `0002-Correct-issue-with-libffi-and-glibc.patch`: This is, unfortunately, a `libffi` fix, not a GHC fix. I'm not enthusiastic about patching libffi like this. However, `libffi`'s upstream is quite unresponsive and we are waiting for them to act on a number of issues, so perhaps we'll need to reconsider this. I've created #14056 to track this. * `0003-do-not-use-SHELL.patch`: Looks reasonable to me. * `0004-reproducible-tmp-names.patch`: Seems plausible. * `0005-buildpath-abi-stability.patch`: There's some discussion in #10424. * `0006-fix-madvise.patch`: Merged in 6576bf83cdf4eac05eb88a24aa934a736c91e3da. See #12865 * `0007-build-hp2ps-twice.patch`, `0008-build-unlit-twice.patch`: Why? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14057> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15262: TH splice containing numeric literal 0 causes heap overflow while cross-compiling
by GHC 16 Jul '18

16 Jul '18

#15262: TH splice containing numeric literal 0 causes heap overflow while cross- compiling -------------------------------------+------------------------------------- Reporter: howtonotwin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Tested off commit `9976bed24dda9449ac2e3e95fb4bf8b379114a28`, running on macOS 10.13.5, trying to compile for iOS. 1. Compile a GHC that cross compiles to `x86_64-apple-ios` (i.e. with `./configure --build=x86_64-apple-darwin --host=x86_64-apple-darwin --target=x86_64-apple-ios; make`). 2. Compile a `ghc-iserv` that can run on the build system (i.e. with `./configure; cd utils/iserv; make`) 3. Try to cross-compile the following file (i.e `x86_64-apple-ios-ghc -fexternal-interpreter -pgmi=path/to/ghc-iserv T.hs`): {{{#!hs {-# LANGUAGE TemplateHaskell #-} module T where $([d| zero = 0 |]) }}} Expected: Compiles fine. Actual: {{{ [1 of 1] Compiling T ( T.hs, T.o ) T.hs:1:1: error: Exception when trying to run compile-time code: heap overflow Code: [d| zero = 0 |] | 1 | {-# LANGUAGE TemplateHaskell #-} | ^ }}} For more fun: * This problem appears to only affect the numeric literal `0`. * `0.0` is not fine. * `1` is fine. * `1 - 1` appears to be a workaround. * `0.1` is fine. * "Burying" the `0` inside another expression is not fine (e.g. `zero = [0]`). * I can even compile most of `singletons`, and it only chokes when the `0` literal first appears (`negate x = 0 - x`). * The `0` has to actually appear in the result. (`$(const [d| |] [d| zero = 0 |])` is fine.) * `0#` is not fine. * This problem only appears when cross-compiling. If I complete the build of the native GHC above and use it instead of the cross-compiler but still use `-fexternal-interpreter`, everything is fine. * Moving the declaration outside of the TH brackets is fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15262> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15136: High CPU when asynchronous exception and unblocking retry on TVar raced
by GHC 16 Jul '18

16 Jul '18

#15136: High CPU when asynchronous exception and unblocking retry on TVar raced -------------------------------------+------------------------------------- Reporter: nshimaza | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Runtime | Version: 8.4.2 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: -------------------------------------+------------------------------------- Detail: https://github.com/nshimaza/race-tmvar-async-exception Runtime falls into high CPU under racing condition between async exception and unblocking retry on TVar. * Reproduces with +RTS -Nx where x > 1 * Does NOT reproduce with +RTS -N1 * Program stalls at `killThread` * High CPU based on given -Nx * CPU won't be 100% if you gave x smaller than available hardware threads of your platform. * Does NOT reproduce if TVar/retry is replaced by MVar * Reproduced with GHC 8.4.2 (macOS High Sierra (10.13.4)) * Reproduced with GHC 8.4.2 (Docker for Mac Version 18.03.1-ce-mac65) * Reproduced with ghc-8.5.20180506 (Docker for Mac Version 18.03.1-ce- mac65) Minimal reproducing code here. (You can find more verbose code on the above github repo.) {{{#!hs main :: IO () main = do let volume = 1000 forM_ [1..1000] $ \i -> do putStrFlush $ show i ++ " " -- Spawn massive number of threads. threads <- replicateM volume $ do trigger <- newTVarIO False tid <- forkIO $ void $ atomically $ do t <- readTVar trigger if t then pure t else retry pure (trigger, tid) -- Make sure all threads are spawned. threadDelay 30000 -- Let threads start to exit normally. forkIO $ forM_ threads $ \(trigger, _) -> threadDelay 1 *> atomically (writeTVar trigger True) -- Concurrently kill threads in order to create race. -- TMVar operation and asynchronous exception can hit same thread simultaneously. -- Adjust threadDelay if you don't reproduce very well. threadDelay 1000 forM_ threads $ \(_, tid) -> do putCharFlush 'A' killThread tid -- When the issue reproduced, this killThread doesn't return. putCharFlush '\b' }}} This program intentionally creates race condition between asynchronous exception and unblocking operation of `retry` on TVar. From one side, a `writeTVar trigger True` is attempted from external thread while target thread is blocking at `retry` on the same `TVar`. On the other side, an asynchronous exception `ThreadKilled` is thrown by yet another external thread to the same target thread. In other word, it attempts to kill a thread about to unblock. I guess when the above two operation hit the same thread at the same time in parallel in SMP environment, GHC runtime falls into high CPU. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15136> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #15246: -fghci-leak-cheak causes many testsuite failures with the quick build flavour
by GHC 16 Jul '18

16 Jul '18

#15246: -fghci-leak-cheak causes many testsuite failures with the quick build flavour -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 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: -------------------------------------+------------------------------------- As [https://mail.haskell.org/pipermail/ghc-devs/2018-May/015812.html originally reported] on the ghc-devs mailing list, the `-fghci-leak-check` flag is causing several tests to fail when GHC is built with the quick build flavour. On my machine, here are all the tests that fail: {{{ Unexpected failures: ghci/prog001/prog001.run prog001 [bad stdout] (ghci) ghci/prog002/prog002.run prog002 [bad stdout] (ghci) ghci/prog003/prog003.run prog003 [bad stdout] (ghci) ghci/prog010/ghci.prog010.run ghci.prog010 [bad stdout] (ghci) ghci/prog013/prog013.run prog013 [bad stdout] (ghci) ghci/prog012/prog012.run prog012 [bad stdout] (ghci) ghci/prog009/ghci.prog009.run ghci.prog009 [bad stdout] (ghci) ghci/scripts/ghci025.run ghci025 [bad stdout] (ghci) ghci/scripts/ghci038.run ghci038 [bad stdout] (ghci) ghci/scripts/ghci057.run ghci057 [bad stdout] (ghci) ghci/scripts/T2182ghci.run T2182ghci [bad stdout] (ghci) ghci/scripts/ghci058.run ghci058 [bad stdout] (ghci) ghci/scripts/T6106.run T6106 [bad stdout] (ghci) ghci/scripts/T8353.run T8353 [bad stdout] (ghci) ghci/scripts/T9293.run T9293 [bad stdout] (ghci) ghci/scripts/T10989.run T10989 [bad stdout] (ghci) ghci/should_run/T13825-ghci.run T13825-ghci [bad stdout] (ghci) ghci.debugger/scripts/print007.run print007 [bad stdout] (ghci) ghci.debugger/scripts/break009.run break009 [bad stdout] (ghci) ghci.debugger/scripts/break008.run break008 [bad stdout] (ghci) ghci.debugger/scripts/break026.run break026 [bad stdout] (ghci) perf/space_leaks/T4029.run T4029 [bad stdout] (ghci) }}} [https://gist.githubusercontent.com/RyanGlScott/f920737287049b82947e1c47cdbc… Here] is the full test output. Generally, the test output discrepancies are all of the form of extra lines of: {{{ +-fghci-leak-check: HomeModInfo for D is still alive! +-fghci-leak-check: ModIface is still alive! +-fghci-leak-check: ModDetails is still alive! +-fghci-leak-check: Linkable is still alive! }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15246> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6