May 2016 - ghc-tickets

[GHC] #11214: Remove JavaScriptFFI from --supported-extensions list
by GHC 18 Oct '16

18 Oct '16

#11214: Remove JavaScriptFFI from --supported-extensions list -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- GHC supports the `JavaScriptFFI` extension syntactically, but it just rejects all `foreign import javascript` declarations in the typechecker. Similar to the change in #11102 I think the proper thing to do is to make GHC say that `JavaScriptFFI` is not supported. Cabal 1.24 can then use this information in dependency resolution. GHCJS would then just add this to the list by itself, since it has its own front end. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11214> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12044: Remove sortWith in favor of sortOn
by GHC 17 Oct '16

17 Oct '16

#12044: Remove sortWith in favor of sortOn -------------------------------------+------------------------------------- Reporter: cblp | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 7.10.3 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 2659 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There is Data.List.sortOn that does the same as GHC.Exts.sortWith, and even seems to be more effective. GHC.Exts.sortWith should be deprecated or removed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12044> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11108: Weak references related crash
by GHC 17 Oct '16

17 Oct '16

#11108: Weak references related crash ----------------------------------------+---------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- I've been getting a Segmentation fault relating to Weak reference use as part of a FRP library (reflex). Attached is a more minimal example which crashes. With debugging on the original problem gave me these problems (on different runs): Most frequently just Segmentation fault (with no stack trace) Occasionally this: {{{ bench: internal error: ASSERTION FAILED: file rts/sm/GCAux.c, line 44 (GHC version 7.10.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} and more rarely this: {{{ bench: internal error: WEAK object entered! (GHC version 7.10.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11108> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #9494: Probable data corruption with GHCi 7.8.* and Zlib
by GHC 15 Oct '16

15 Oct '16

#9494: Probable data corruption with GHCi 7.8.* and Zlib -------------------------------------+------------------------------------- Reporter: nominolo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following program causes Zlib data corruption errors when run from inside GHCi. It launches two threads which then concurrently read a file, compress it, and immediately decompress it. You need libraries `zlib`, `SHA`, and `async`. {{{ module Main where import qualified Codec.Compression.Zlib as Zlib import qualified Data.ByteString.Lazy as BL import qualified Data.ByteString.Internal as BI import Control.Exception (bracket) import Control.Concurrent import Control.Monad import Control.Exception ( evaluate) import Data.Digest.Pure.SHA ( sha1) -- from the 'SHA' package import Control.Concurrent.Async ( mapConcurrently) import System.Mem ( performGC ) import Debug.Trace test :: Int -> IO String test _ = do tid <- myThreadId -- testdata is: dd if=/dev/urandom of=/tmp/testdata bs=100k count=100 -- Could also be replaced by: (BL.take (10^7) "/dev/urandom") dat <- BL.readFile "/tmp/testdata" let cbuf = Zlib.compress $ traceChunks tid $ dat s <- evaluate $ sha1 $ Zlib.decompress $ cbuf return $ show s where -- We used this to check whether buffers were reused by different threads, but that -- doesn't seem to be the case. Removing the call to traceChunks, however, makes it -- harder to reproduce possibly because of scheduler effects. In a much larger program -- it could be reproduced more easily without the trace, but in this small example -- tracing seems to cause the right amount of nondeterminism. traceChunks tid bs = BL.fromChunks $ zipWith (\n x -> trace (show tid ++ ":" ++ showBS x) x) [1..] $ BL.toChunks bs showBS (BI.PS ptr off len) = show ptr main = do r <- withGCThread $ mapConcurrently (test) ([1..2] :: [Int]) putStrLn $ show $ r where -- Regularly forcing the GC makes the test-case more reproducible. withGCThread io = bracket (forkIO $ forever $ performGC >> threadDelay 1000) killThread (const io) }}} The output should be something like: {{{ ... ThreadId 51:0x00000001091ee010 ThreadId 49:0x00000001091a7010 ... ThreadId 49:0x000000010986f010 zlib-test-case.hs: user error (Codec.Compression.Zlib: incorrect data check) }}} You'll get different Zlib errors, depending on where it detects the inconsistency. Sometimes Zlib doesn't throw an error, but the checksums are different. So far we've only been able to reproduce this using GHCi 7.8.3 on both Linux (NixOS) and Mac. We haven't been able to trigger it with a compiled executable, nor with GHCi 7.6.3. It '''was''' reproducable with HEAD from Jan 30 (I had that lying around somewhere). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9494> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9685: GHC fails to build with mingw32-make on Windows
by GHC 15 Oct '16

15 Oct '16

#9685: GHC fails to build with mingw32-make on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: gintas Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It would be nice to be able to build ghc on Windows with mingw32-make which is bundled with the prebuilt gcc package that we are using for the ghc build. mingw32-make might be faster (due to less overhead associated with POSIX compatibility, forks etc.) and more reliable - msys2's make is a bit glitchy because it needs to fork off a lot of processes and sometimes runs into issues with fork(), which should not be a problem for mingw32-make. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9685> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10437: RunHaskell error in HSExtra on Win64
by GHC 15 Oct '16

15 Oct '16

#10437: RunHaskell error in HSExtra on Win64 -------------------------------------+------------------------------------- Reporter: | Owner: ScottSedgwick | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Operating System: Windows Keywords: runhaskell | Type of failure: Compile-time Architecture: x86_64 | crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I ran the following command, and got this error: {{{ $ runhaskell shakefile.hs clean shakefile.hs: C:\Users\Scott Sedgwick\AppData\Roaming\cabal\x86_64 -windows-ghc-7.8.3\extra-1.2\HSextra-1.2.o: Not x86_64 PEi386 shakefile.hs: shakefile.hs: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): loadObj "C:\\Users\\Scott Sedgwick\\AppData\\Roaming\\cabal\\x86_64-windows- ghc-7.8.3\\extra-1.2\\HSextra-1.2.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The shakefile in question looks like this: {{{ import Development.Shake import Development.Shake.FilePath --import System.Info srcFiles = [ "source/main.hs", "source/DBDataStructures.hs", "source/FormatDBData.hs", "source/GetDBData.hs", "source/ParseDBData.hs"] exeFile = "dist/build/mssql-er/mssql-er.exe" depFiles = [ "dependencies/erd/erd.exe", "dependencies/dot/Pathplan.dll", "dependencies/dot/config6", "dependencies/dot/gvc.dll", "dependencies/dot/iconv.dll", "dependencies/dot/libfontconfig-1.dll", "dependencies/dot/libgmodule-2.0-0.dll", "dependencies/dot/libpango-1.0-0.dll", "dependencies/dot/libpangowin32-1.0-0.dll", "dependencies/dot/ltdl.dll", "dependencies/dot/cdt.dll", "dependencies/dot/dot.exe", "dependencies/dot/gvplugin_dot_layout.dll", "dependencies/dot/libcairo-2.dll", "dependencies/dot/libfreetype-6.dll", "dependencies/dot/libgobject-2.0-0.dll", "dependencies/dot/libpangocairo-1.0-0.dll", "dependencies/dot/libpng14-14.dll", "dependencies/dot/zlib1.dll", "dependencies/dot/cgraph.dll", "dependencies/dot/freetype6.dll", "dependencies/dot/gvplugin_pango.dll", "dependencies/dot/libexpat.dll", "dependencies/dot/libglib-2.0-0.dll", "dependencies/dot/libgthread-2.0-0.dll", "dependencies/dot/libpangoft2-1.0-0.dll", "dependencies/dot/libxml2.dll"] copyDep :: FilePath -> Action() copyDep src = do let dst = "dist" </> (dropDirectory1 (dropDirectory1 src)) copyFile' src dst main :: IO() main = shakeArgs shakeOptions $ do want ["deploy"] "clean" ~> do cmd "cabal" "clean" "dist/setup-config" *> \_ -> do need ["mssql-er.cabal"] cmd "cabal" "configure" "--enable-tests" "configure" ~> do need ["dist/setup-config"] exeFile *> \_ -> do need (["configure"] ++ srcFiles) cmd "cabal" "build" "build" ~> do need [exeFile, "test"] "test" ~> do need srcFiles cmd "cabal" "test" "deploy" ~> do need ["build"] mapM_ copyDep depFiles }}} Strangely, if I compile that shakefile using ghc, then run it, it works correctly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10437> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10122: PolyKinds: inferred type not as polymorphic as possible
by GHC 15 Oct '16

15 Oct '16

#10122: PolyKinds: inferred type not as polymorphic as possible -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In the user's guide on [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/kind- polymorphism.html kind polymorphism] the following example is presented: {{{#!hs f1 :: (forall a m. m a -> Int) -> Int -- f1 :: forall (k:BOX). -- (forall (a:k) (m:k->*). m a -> Int) -- -> Int }}} "Here in f1 there is no kind annotation mentioning the polymorphic kind variable, so k is generalised at the top level of the signature for f1, making the signature for f1 is as polymorphic as possible." When I ask GHCi for the type of `f1`, it is however not as polymorphic as possible: {{{ > :t f1 f1 :: (forall a (m :: * -> *). m a -> Int) -> Int }}} Trying to compile the following program: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ExplicitForAll #-} {-# LANGUAGE Rank2Types #-} module PolyFail where f :: (forall a m. m a -> Int) -> Int f g = g (Just 3) }}} Results in this error: {{{ [1 of 1] Compiling PolyFail ( PolyFail.hs, PolyFail.o ) PolyFail.hs:8:10: Kind incompatibility when matching types: m0 :: k -> * Maybe :: * -> * Expected type: m0 a0 Actual type: Maybe a1 Relevant bindings include g :: forall (a :: k) (m :: k -> *). m a -> Int (bound at PolyFail.hs:8:3) f :: (forall (a :: k) (m :: k -> *). m a -> Int) -> Int (bound at PolyFail.hs:8:1) In the first argument of ‘g’, namely ‘(Just 3)’ In the expression: g (Just 3) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10122> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12053: Mode for ghc --make which only compiles the files I pass on command line
by GHC 14 Oct '16

14 Oct '16

#12053: Mode for ghc --make which only compiles the files I pass on command line -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Here are a few situations where GHC picks up "too many" files when running `--make`: * Suppose a user doesn't add enough modules to `exposed-modules`/`other- modules` in Cabal. GHC will happily pick up extra source files, but those files won't get bundled in the `sdist` or be included in ABI computation. Difficult for Cabal to tell when this has happened. * Suppose the user wants to define multiple internal libraries, and give them the same hs-source-dir. This won't work: because GHC sees the source file it will prefer it over the external dependency. There's a very easy thing that GHC could do to make this better: add a mode to `--make` which says "only compile the files that are explicitly passed on the command line." Something like `ghc --make --only A.hs` will only build A.hs, and error if you try to import B.hs. Seems like this should be fairly easy to do, and would help solve a lot of problems related to GHC slurping up too many files. (I've assigned myself because this is a blocker for backpack, but if someone wants to take a crack at this be my guest.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12053> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10798: Signatures with only types should not be included in unit keys
by GHC 14 Oct '16

14 Oct '16

#10798: Signatures with only types should not be included in unit keys -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Priority: normal | Milestone: ⊥ Component: Package | Version: 7.11 system | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Suppose we want to modularize the dependence on `p` in this program: {{{ unit p where module A where data T = T mkT = T unit q where include p module B where import A bar = mkT }}} The obvious signature to write for `A` is: {{{ signature A where data T mkT :: T }}} But this presupposes an implementation of `A` which exports `T`. But `B` doesn't use any export of `T`, and an equally valid implementation would be if `T` was defined in some `Types` module and then imported here. But suppose we change our signature to be: {{{ signature A.Types where data T signature A where import A.Types mkT :: T }}} This is maximally general, but requires that the module which exports `T` be named `A.Types`. If someone puts the type anywhere else, we have to rename the signature to the real place it was defined, or make a dummy implementation module which reexports the type in question. Now there is a curious thing, which is that the choice of module we use to fill these extra signature modules currently influences the type identity of anything else in the unit. But we never rely on any code from these signatures: if I make two distinct dummy modules to set `T` to the same type, this really shouldn't have any impact (at all!) on the code generated. So, my suggestion is that if a signature contains only types (perhaps they could be named something else, like `tysignature`), they should not count towards the calculation of a unit key. This means that a user can freely create dummy modules to fill in these types when they are instantiating; all that is being done is helping Backpack figure out what the identities of types are. (If we wanted to be fancy, Backpack could even look inside type signatures to determine some types, but let's not go there for now.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10798> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9717: More lazy orphan module loading
by GHC 14 Oct '16

14 Oct '16

#9717: More lazy orphan module loading -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.9 checker) | Operating System: Keywords: backpack | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, when we import a module, we eagerly load all of the orphan modules transitively reachable from it (TcRnDriver:tcRnImports). This is a bit of bummer: as module import hierarchies get deeper and deeper, we'll collect more and more orphan instances and load more and more modules eagerly. The idea is to try to arrange for an orphan module not to be loaded, unless we think that it might have a relevant instance. Instead of just recording a list of orphan modules transitively reachable from a module, we will also record a digest of what type classes and types the orphan provides instances for. (This will be similar to the data we record for `ifInstTys` in `IfaceClsInst`.) Now, when we do any operation involving instances, we check and see if there are also orphans which could provide relevant instances (based on the digest) and load those. If an instance could never have been used, we avoid loading its interface file entirely. This doesn't appear to help too much for type families, where we have to load all of the instances anyway in order to check for consistency. A choice to make: Should we record just the class, or also the types involved? It would be best if we could quickly conclude that there are no more instances to load, but this may be difficult if matching against types as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9717> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4