May 2015 - ghc-tickets

[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] #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

[GHC] #10458: GHCi fails to load shared object (the 'impossible' happened)
by GHC 10 Oct '16

10 Oct '16

#10458: GHCi fails to load shared object (the 'impossible' happened) -----------------------------------------+--------------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------------- I have a project that uses two external libraries, namely `-lcrypt` and `-lpcre`. Building with `cabal` and running the resulting executable works as expected, but I'm having trouble starting a REPL in GHCi: {{{ % cabal repl Preprocessing executable 'etamoo' for EtaMOO-0.2.1.0... GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help /usr/bin/ld: dist/build/etamoo/etamoo-tmp/src/cbits/crypt.o: relocation R_X86_64_PC32 against undefined symbol `crypt' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status }}} The error suggests I need `-fPIC`, and this seems to help the `-lcrypt` case, but now I get: {{{ % cabal repl --ghc-options="-fPIC" Preprocessing executable 'etamoo' for EtaMOO-0.2.1.0... GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc21539_0/libghc21539_2.so: undefined symbol: pcre_callout Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} FYI the C type of `pcre_callout` is a little unusual: {{{ extern int (*pcre_callout)(pcre_callout_block *); }}} In other words it is a global variable (pointer to function), not a function itself. Any advice is welcome, including the proper way to start GHCi given these external dependencies, as well as on this apparent bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10458> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 46

[GHC] #9877: ForeignImport coercion evaluated before typechecking
by GHC 09 Oct '16

09 Oct '16

#9877: ForeignImport coercion evaluated before typechecking -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Compile- Difficulty: Unknown | time crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Under Windows 8.1 x64 with Haskell Platform 2014.02 and EclipseFP I got: buildwrapper.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): ForeignImport coercion evaluated before typechecking on the first line of file that has: {{{ #!div style="font-size: 80%" Code highlighting: {{{#!haskell {-# LANGUAGE ForeignFunctionInterface, RankNTypes, OverloadedStrings, ScopedTypeVariables #-} module Persist( persistWrite, persistRead ) where import System.Win32.Types import Graphics.Win32.GDI.Types import Foreign.C.String import Foreign.Marshal.Array import Control.Exception foreign import ccall unsafe "SHGetFolderPathW" cSHGetFolderPathW :: HWND -> INT -> HANDLE -> DWORD -> CWString -> IO LONG }}} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9877> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9547: Empty constraint tuples are mis-kinded
by GHC 06 Oct '16

06 Oct '16

#9547: Empty constraint tuples are mis-kinded -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Consider {{{ -- If :: forall k. 'Bool -> k -> k -> k type family If cond tru fls where If True tru fls = tru If False tru fls = fls foo :: If True () (Eq a) => a -> a foo = error "urk" }}} This should work fine. But we get {{{ Foo.hs:8:21: The third argument of `If' should have kind `*', but `Eq a' has kind `Constraint' In the type signature for `foo': foo :: If True () (Eq a) => a -> a }}} Reason: GHC is treating the `()` unit tuple as of kind `*`. Reason is that in the `HsTupleTy` case of `tc_hs_type` in `TcHsType`, we see {{{ -- In the [] case, it's not clear what the kind is, so guess * }}} And that guess is plain wrong in this case. Unfortunately I don't see an easy fix, but it's plain wrong as-is. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9547> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10163: Export typeRepKinds in Data.Typeable
by GHC 04 Oct '16

04 Oct '16

#10163: Export typeRepKinds in Data.Typeable -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: feature | Milestone: request | Version: 7.10.1-rc3 Priority: normal | Operating System: Unknown/Multiple Component: | Type of failure: Other libraries/base | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Now that {{{TypeRep}}} has a {{{[KindRep]}}} field internally, {{{Data.Typeable}}} should export {{{typeRepKinds}}} (alongside {{{typeRepTyCon}}} and {{{typeRepArgs}}}, which are currently exported) to allow users to access it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10163> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits
by GHC 01 Oct '16

01 Oct '16

#8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ----------------------------+--------------------------------------- Reporter: facundoq | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------------- Windows shows a window that says "GHC has stopped working" when compiling a simple hello world. Steps to reproduce 1) Download GHC 7.8 RC2 (http://www.haskell.org/ghc/dist/7.8.1-rc2/ghc-7.8.0.20140228-i386 -unknown-mingw32.tar.bz2) 2) Extract the contents of the tar to folder $GHC$ 3) Add $GHC$\bin and $GHC$\mingw\bin folder to the PATH, add env var "LANG=C". 4) Create file test.hs with contents: main = putStrLn "Hello, World!" 5) run "ghc test.hs". Interestingly, the error is not deterministic, ie, after running the command several times the program gets compiled. When that happens, and ff the file test.o is not deleted, further attempts to compile run succesfully. GHCi appears to work normally (when doing simple tests). More details: http://stackoverflow.com/questions/22291739/cant-install-packages-with- cabal-using-ghc-7-8rc2-and-windows-7 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8870> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #9520: Running an action twice uses much more memory than running it once
by GHC 29 Sep '16

29 Sep '16

#9520: Running an action twice uses much more memory than running it once -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime Difficulty: Unknown | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This started as a [http://www.haskell.org/pipermail/haskell- cafe/2014-August/115751.html Haskell cafe discussion] about conduit. This may be related to #7206, but I can't be certain. It's possible that GHC is not doing anything wrong here, but I can't see a way that the code in question is misbehaving to trigger this memory usage. Consider the following code, which depends on conduit-1.1.7 and conduit- extra: {{{#!hs import Data.Conduit ( Sink, (=$), ($$), await ) import qualified Data.Conduit.Binary as CB import System.IO (withBinaryFile, IOMode (ReadMode)) main :: IO () main = do action "random.gz" --action "random.gz" action :: FilePath -> IO () action filePath = withBinaryFile filePath ReadMode $ \h -> do _ <- CB.sourceHandle h $$ CB.lines =$ sink2 1 return () sink2 :: (Monad m) => Int -> Sink a m Int sink2 state = do maybeToken <- await case maybeToken of Nothing -> return state Just _ -> sink2 $! state + 1 }}} The code should open up the file "random.gz" (I simply `gzip`ed about 10MB of data from /dev/urandom), break it into chunks at each newline character, and then count the number of lines. When I run it as-is, it uses 53KB of memory, which seems reasonable. However, if I uncomment the second call to `action` in `main`, maximum residency shoots up to 45MB (this seems to be linear in the size of the input file. I additionally tried copying `random.gz` into two files, `random1.gz` and `random2.gz`, and changed the two calls to `action` to use different file names. It still resulted in large memory usage. I'm going to continue working to make this a smaller reproducing test case, but I wanted to start with what I had so far. I'll also attach the core generated by both the low-memory and high-memory versions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9520> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17