April 2018 - ghc-tickets

[GHC] #12606: Linux (ELF) Support for "ghc -static -shared"
by GHC 19 Jul '18

19 Jul '18

#12606: Linux (ELF) Support for "ghc -static -shared" ----------------------------------------+--------------------------------- Reporter: tmobile | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- On some platforms it is possible to create a stand-alone shared library out of some object `Foo.o` including foreign exports with something like: `ghc -static -shared Foo.o ...` The resulting library will have `Foo`'s dependencies including `base` as well as the RTS statically linked in. On BSDs this is possible because generating position independent code is the default there, and on Windows this is possible because the dynamic loader uses some magic that doesn't require position independent code. Unfortunately on Linux this is not possible because `libHSbase`, `libHSrts`, etc. are not built with `-fPIC` unless one specifically asks for it when building GHC. As far as I know this is the only way to get `-static -shared` to work on this platform. There are use cases for compiling Haskell code into a single shared object that does not have additional runtime dependencies. Suppose one wishes to write a plugin for a program in Haskell. It would be nice to provide the plugin as a single shared object, rather than requiring GHC's libraries to be present at runtime as well. An easy solution might be adding a switch to the configure script or `build.mk` to make it easier to build GHC+libs with `-fPIC` on Linux. Ideally it would be possible to build and install both PIC and non-PIC libraries and have GHC choose the correct one at link time based on the flags and target platform, since PIC code carries a small space/performance overhead and isn't necessary on Linux in most cases. I don't know my way around GHC(outside of the GHC API) or the build system that well yet, but if adding extra build system flags and GHC link-time flag handling code to make this work is an acceptable solution I'm happy to spend the time to get this working. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12606> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13194: Concurrent modification of package.cache is not safe
by GHC 18 Jul '18

18 Jul '18

#13194: Concurrent modification of package.cache is not safe -------------------------------------+------------------------------------- Reporter: arybczak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | 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: -------------------------------------+------------------------------------- There are a couple of different issues here. 1. On Linux, issuing `ghc-pkg register` for multiple packages in parallel might result in lost updates to package database because of how `registerPackage` function works - it reads existing package databases, picks the one to modify, then checks that package info for the package to register is fine and replaces package database with what was read in the beginning + new package info. Therefore, if updates interleave, it might happen that process1 reads the database, then process2 updates it while process1 still has the old version and uses it for its update later, so update made by process2 is lost. 2. On Windows, update to package database might fail - the issue is that GHC attempts to update it using rename trick, which fails whenever any other process has file to be replaced open for reading. Combine that with the fact that GHC reads package database when compiling packages and you get problems in both Stack (https://github.com/commercialhaskell/stack/issues/2617) and Cabal (https://github.com/haskell/cabal/issues/4005) BTW, rename trick (used for atomic database updates) not only doesn't work on Windows, it's also not atomic e.g. on NFS (https://stackoverflow.com/questions/41362016/rename-atomicity-and-nfs) The solution to both problems is to use OS specific features to lock database file (in shared mode when reading and in exclusive mode when writing). This can be done on Windows using LockFileEx. Unfortunately for POSIX things are a bit more complicated. There are two ways to lock a file on Linux: 1. Using fcntl(F_SET_LK) (POSIX API) 2. Using flock (BSD API) However, fcntl locks have a serious limitation: The record locks described above are associated with the process (unlike the open file description locks described below). This has some unfortunate consequences: * If a process closes any file descriptor referring to a file, then all of the process's locks on that file are released, regardless of the file descriptor(s) on which the locks were obtained. This is bad: it means that a process can lose its locks on a file such as /etc/passwd or /etc/mtab when for some reason a library function decides to open, read, and close the same file. * The threads in a process share locks. In other words, a multithreaded program can't use record locking to ensure that threads don't simultaneously access the same region of a file. Whereas flock is not guaranteed to work with NFS, according to https://en.wikipedia.org/wiki/File_locking#Problems: Whether and how flock locks work on network filesystems, such as NFS, is implementation dependent. On BSD systems, flock calls on a file descriptor open to a file on an NFS-mounted partition are successful no-ops. On Linux prior to 2.6.12, flock calls on NFS files would act only locally. Kernel 2.6.12 and above implement flock calls on NFS files using POSIX byte-range locks. These locks will be visible to other NFS clients that implement fcntl-style POSIX locks, but invisible to those that do not.[4] Assuming that the solution would be to go with locking the database, we would need to: 1. In `registerPackage`, lock all read databases in shared mode except for the database that will later be modified, which has to be locked in exclusive mode. The handle also would need to be kept open and passed to `changeDB` later and used for rewriting the database with updated version in `GHC.PackageDb.writePackageDb` instead of `writeFileAtomic` (which is not actually unconditionally atomic, as demonstrated above). 2. `GHC.PackageDb.decodeFromFile` would lock a file in appropriate mode and return the handle to open file if appropriate. 3. Add support for locking a file. This should be fairly easy to do in GHC.IO.Handle.FD by extending function `openFile'` with appropriate parameters and then adding wrapper function `openLockedFile` or something. We can add both blocking and non-blocking locking to make ghc-pkg show information about waiting for locked package database if appropriate. Alternatively we could add a function similar to the following: `hLock :: Handle -> LockMode -> Bool{-block-} -> IO Bool`, but that requires extracting file descriptor from Handle, which as far as I see is problematic. Is going with locking an acceptable solution here? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13194> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[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] #13812: deriveConstants: no objdump program given (OpenBSD)
by GHC 15 Jul '18

15 Jul '18

#13812: deriveConstants: no objdump program given (OpenBSD) -------------------------------------+------------------------------------- Reporter: roland | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Keywords: | Operating System: OpenBSD Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: #9549 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Building HEAD on OpenBSD 6.1 fails with: {{{ inplace/bin/deriveConstants --gen-header -o includes/dist- derivedconstants/header/DerivedConstants.h --tmpdir includes/dist- derivedconstants/header/ --gcc-program "gcc" --gcc-flag -W all --gcc-flag -std=gnu99 --gcc-flag -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc-flag -Iincludes/dist- derivedconstants/header --gcc-flag -Iincludes/di st-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon --nm-program "nm" --target-os "openbsd" deriveConstants: no objdump program given }}} This can be fixed in configure.ac (see attached patch). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13812> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14525: Backpack doesn't work with CPP
by GHC 14 Jul '18

14 Jul '18

#14525: Backpack doesn't work with CPP -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Steps to repro: 1. Create a package with a signature and a module which imports it 2. Add `{-# LANGUAGE CPP #-}` to the module Expected result: it works Actual result: {{{ <command line>: unknown package: hole }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14525> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3