July 2018 - ghc-tickets

[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] #15403: Compact Regions with Lazy Evaluation
by GHC 17 Jul '18

17 Jul '18

#15403: Compact Regions with Lazy Evaluation -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- Currently, adding a value to a compact region evaluates it to normal form. I'm wondering if it's possible to have another compacting primitive that can add unevaluated thunks to a compact region. These thunks would be evaluated as they were demanded, and the resulting values would be added to the compact region. I actually have a use case for this in mind involving very large map-like data structures whose size exceeds system memory when in normal form but that are largely unevaluated, giving them a memory footprint that is a fraction of what it would be. One problem would be that a compaction failure (from someone trying to stick a function or a `MutableArray#` into a compact region) would happen after the call to `compactLazy`, so you end up with all the usual lazy IO problems. Another problem would be that the thunks wouldn't get GCed, since they would live in a compact region (and also because you could not update the references to the thunk, since compact regions are not scanned during GC). Neither of these are absolute deal-breakers though. Are there other problems that make this fundamentally impossible to do? Or is this something that could conceivably be added? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15403> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[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] #15405: Typo in trac ticket number
by GHC 17 Jul '18

17 Jul '18

#15405: Typo in trac ticket number -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- This line should refer to trac issue #14873 not #114873 https://github.com/ghc/ghc/blob/53649947223f197cf93e26393486f578d56c46c6/co… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15405> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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] #15400: Parse error on input ‘*’
by GHC 16 Jul '18

16 Jul '18

#15400: Parse error on input ‘*’ -------------------------------------+------------------------------------- Reporter: Bodigrim | 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: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Both GHC 8.6.1-alpha1 and 8.6.1-alpha2 fail to build `numtype-dk` package, while GHC 8.4.3 and HEAD work fine. {{{ Configuring numtype-dk-0.5.0.1... Preprocessing library for numtype-dk-0.5.0.1.. Building library for numtype-dk-0.5.0.1.. Numeric/NumType/DK/Integers.hs:38:29: error: parse error on input ‘*’ | 38 | type (+), type (-), type (*), type (/), type (^), | }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15400> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[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