August 2017 - ghc-tickets

[GHC] #10972: Add a :binfo (beginner info) GHCi command
by GHC 15 Jan '18

15 Jan '18

#10972: Add a :binfo (beginner info) GHCi command -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10963 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From goldfire: > Add a new command to GHCi, :binfo (for "beginner info") (please suggest a better name) that is like :info but presents different information. It suppresses in-scope instances, but attempts to specialize a function's type and presents specializations, using heuristics. So when we say :binfo find, we'll see Foldable t => (a -> Bool) -> t a -> Maybe a but also (a -> Bool) -> [a] -> Maybe a. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10972> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13647: Tidy up TcTypeable
by GHC 15 Jan '18

15 Jan '18

#13647: Tidy up TcTypeable -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- There is code in `TcTypeable` that generates a `KindRep` for each `TyCon` (see `Note [Representing TyCon kinds: KindRep]`). There's nothing actually wrong with it. But it's pretty hard to understand. And it generates a staggering amount of data structure, when compiling `GHC.Types`. {{{ Result size of Tidy Core = {terms: 74,615, types: 41,335, coercions: 2, joins: 0/0} }}} Why? Well, it injects a `TyCon` binding for each unboxed tuple size. For example, here is the code for pairs `(#,#)` {{{ $tc(#,#) = TyCon 16533601304077481746## 7902994497850328874## tr$ModuleGHCPrim $tc(#,#)2 2# $tc(#,#)1 -- TYPE #0 -> TYPE #1 -> TYPE (TupleRep (': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep)))) $tc(#,#)1 :: KindRep $tc(#,#)1 = KindRepFun $krep2115_r6ji $krep18009_rarE $krep18009_rarE = KindRepFun $krep2117_r6jk $krep18008_rarD -- TYPE (TupleRep (': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep)))) $krep18008_rarD = KindRepTyConApp $tcTYPE $krep18007_rarC $krep18007_rarC = : @ KindRep $krep18006_rarB ([] @ KindRep) -- TupleRep (': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep))) $krep18006_rarB = KindRepTyConApp $tc'TupleRep $krep18005_rarA $krep18005_rarA = : @ KindRep $krep2283_r6m0 ([] @ KindRep) -- ': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep)) $krep2283_r6m0 = KindRepTyConApp $tc': $krep2282_r6lZ $krep2282_r6lZ = : @ KindRep $tc'AddrRep1 $krep2281_r6lY $krep2281_r6lY = : @ KindRep $krep61_r5Ma $krep2280_r6lX $krep2280_r6lX = : @ KindRep $krep2279_r6lW ([] @ KindRep) -- ': RuntimeRep #1 ('[] RuntimeRep) $krep2279_r6lW = KindRepTyConApp $tc': $krep2278_r6lV $krep2278_r6lV = : @ KindRep $tc'AddrRep1 $krep2277_r6lU $krep2277_r6lU = : @ KindRep $krep60_r5M9 $krep2276_r6lT $krep2276_r6lT = : @ KindRep $krep2274_r6lR ([] @ KindRep) -- '[] RuntimeRep $krep2274_r6lR = KindRepTyConApp $tc'[] $krep2273_r6lQ $krep2273_r6lQ = : @ KindRep $tc'AddrRep1 ([] @ KindRep) -- RuntimeRep $tc'AddrRep1 = KindRepTyConApp $tcRuntimeRep ([] @ KindRep) -------------- TYPE #0 $krep2115_r6ji = KindRepTyConApp $tcTYPE $krep2114_r6jh $krep2114_r6jh = : @ KindRep $krep61_r5Ma ([] @ KindRep) $krep61_r5Ma = KindRepVar 0# -------------- TYPE #1 $krep2117_r6jk = KindRepTyConApp $tcTYPE $krep2116_r6jj $krep2116_r6jj = : @ KindRep $krep60_r5M9 ([] @ KindRep) $krep60_r5M9 = KindRepVar 1# }}} That's a lot, and it's only for pairs. We generate all this up to 62-tuples! Suggestions (read `Note [Representing TyCon kinds: KindRep]` first) * `KindRep` is a description of a polykind; an interpreter, called `instantiateKindRep` turns it into a kind. So we can add whatever constructors we like to `KindRep`. * One good one would be `UnboxedTupleRep n`, which `instantiateKindRep` can instantiate to the kind of an unboxed tuple. It just moves the work somewhere else, of course, but it will make the generated code dramatically smaller. * We have a few canned kind-reps, via `TcTypeable.builtInKindReps`. It'd be simpler and easier instead to make each of them into a data constructor of `KindRep`. * Once that is done, I suspect that the entire machinery of tyring to share `KindReps` (which makes my head hurt) would be unnecessary None of this is essential, but I think that matters can be improved. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13647> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9285: IO manager startup procedure somewhat odd
by GHC 15 Jan '18

15 Jan '18

#9285: IO manager startup procedure somewhat odd ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently the RTS startup procedure for the threaded runtime with a single capability looks something like this: '''1. Capability gets initialized''' {{{ hs_main real_main hs_init_ghc initScheduler initCapabilities }}} '''2. IO Manager is started''' {{{ hs_main real_main hs_init_ghc ioManagerStart }}} '''3. ensureIOManagerIsRunning''' The IO manager of course is mostly written in Haskell, so `ioManagerStart` does {{{ cap = rts_lock(); rts_evalIO(&cap,&base_GHCziConcziIO_ensureIOManagerIsRunning_closure,NULL); rts_unlock(cap); }}} '''4. Bound task is created and we start running Haskell code''' Since this is the first call to `rts_lock`, it creates a bound task to correspond to the current OS thread. '''5. Haskell code does a safe FFI call: create worker task 1''' The first safe FFI call that the IO manager makes (ignoring `labelThread`) is to `c_setIOManagerControlFd`. At this point, the bound task gets suspended and we create a worker task. '''6. Worker task 1 starts executing `GHC.Event.Manager.loop`''' The worker tasks gets suspended due to an explicit call to `yield` in `GHC.Event.Manager.step`, at which point the bound task continues execution. It continues and finishes (`ensureIOManagerRunning` completes). The worker task takes over. '''7. Worker task 1 does a safe FFI call to `I.poll`, create new worker task 2''' (This safe call is from `GHC.Event.Manager.step`) '''8. Worker task 2 executes `GHC.Event.TimerManager.loop`, and does safe FFI call to `I.poll`; create worker task 3''' This worker task will remain spare for now. '''9. Start executing the actual main function''' The IO manager calls `rts_unlock`, which verifies if there are any spare workers available; it finds that there are and doesn't start a new one. Then when we start `main` itself of course we go through this `rts_lock, rts_evalIO, rts_unlock` sequence ''again''. This is somewhat confusing, and makes tracing the startup of the code more difficult to interpret. It seems that this could be simpler: only a single `rts_lock` should be necessary, in which we first call `ensureIOManagerIsRunning` and then `main`, followed by a single `rts_unlock`. A similar simplification should be possible in `forkProcess`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9285> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13752: Odd pattern synonym type errors
by GHC 14 Jan '18

14 Jan '18

#13752: Odd pattern synonym type errors -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc2 (Type checker) | Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Suppose we have {{{#!hs newtype Arrange = Arrange {getArrange :: [Int] -> [Int]} }}} If I write {{{#!hs pattern Heh :: (c ~ ((~) Int)) => (forall a. c a => [a] -> [a]) -> Arrange pattern Heh f <- Arrange f }}} I get {{{ • Couldn't match type ‘[Int] -> [Int]’ with ‘forall a. Int ~ a => [a] -> [a]’ Expected type: forall a. c a => [a] -> [a] Actual type: [Int] -> [Int] • In the declaration for pattern synonym ‘Heh’ }}} It surprises me that these don't match. I can hack around that a bit: {{{#!hs newtype Help = Help {getHelp :: forall a. Int ~ a => [a] -> [a]} pattern Heh :: (c ~ ((~) Int)) => (forall a. c a => [a] -> [a]) -> Arrange pattern Heh f <- ((\x -> Help (getArrange x)) -> Help f) }}} Now this compiles, and I can use it in a variety of ways, but not quite all. If I write {{{#!hs pattern Heh' :: ([Int] -> [Int]) -> Arrange pattern Heh' f <- Heh f }}} I get {{{ Haha.hs:78:23: error: • Couldn't match expected type ‘[Int] -> [Int]’ with actual type ‘forall a. Int ~ a => [a] -> [a]’ • In the declaration for pattern synonym ‘Heh'’ | 78 | pattern Heh' f <- Heh f | ^ }}} This strikes me as perhaps even more surprising. I can hack around that too, of course, but yuck! {{{#!hs pattern Heh' :: ([Int] -> [Int]) -> Arrange pattern Heh' f <- ((\(Heh g) -> g @ Int) -> f) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13752> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10634: Type class with bijective type functions
by GHC 14 Jan '18

14 Jan '18

#10634: Type class with bijective type functions -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- See the attached module. {{{ $ cat TypeFunctionBijection.hs {-# LANGUAGE TypeFamilies #-} module TypeFunctionBijection where import Data.Int (Int8, Int16, Int32) type family Up a type instance Up Int8 = Int16 type instance Up Int16 = Int32 class (Up (Down a) ~ a) => Convert a where type Down a down :: a -> Down a instance Convert Int16 where type Down Int16 = Int8 down = fromIntegral instance Convert Int32 where type Down Int32 = Int16 down = fromIntegral x :: Int8 x = down 8 }}} {{{ $ ghci-7.8.4 -Wall TypeFunctionBijection.hs GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling TypeFunctionBijection ( TypeFunctionBijection.hs, interpreted ) Ok, modules loaded: TypeFunctionBijection. *TypeFunctionBijection> :q Leaving GHCi. }}} {{{ $ ghci-7.10.1 -Wall TypeFunctionBijection.hs GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling TypeFunctionBijection ( TypeFunctionBijection.hs, interpreted ) TypeFunctionBijection.hs:24:5: Couldn't match expected type ‘Int8’ with actual type ‘Down a0’ The type variable ‘a0’ is ambiguous In the expression: down 8 In an equation for ‘x’: x = down 8 Failed, modules loaded: none. Prelude> :q Leaving GHCi. }}} Up to GHC-7.8.4 I could make a type function like `Down` a bijection by adding equality constraints to the `Convert` class. In GHC-7.10.1 this fails. Is this a bug or a feature? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10634> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13903: KQueue evtmgr backend fails to register for write events
by GHC 13 Jan '18

13 Jan '18

#13903: KQueue evtmgr backend fails to register for write events -------------------------------------+------------------------------------- Reporter: waldheinz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 System | Keywords: | Operating System: FreeBSD Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The root of the problem is that the `GHC.Event.KQueue.toFilter` function has type `GHC.Event.Internal.Event -> Filter` with GHC's `Event` being a bitmask which can represent read events, write events or a combination of those. It happens that the event manager requests it's backend to be notified about read ''and'' write events on some fd, and because the kqueue `EVFILT_*`s are ''not'' bitmasks, the above function cannot capture this, silently dropping the desire to be notified about write events. The following program triggers the problematic behaviour: {{{ import Control.Concurrent ( forkIO, killThread ) import Control.Exception ( finally ) import Control.Monad.Trans.Resource ( runResourceT ) import Control.Monad.IO.Class ( liftIO ) import qualified Data.ByteString as BS import Data.Conduit ( ($$), ($=) ) import qualified Data.Conduit.Binary as CB import qualified Data.Conduit.List as CL import qualified Data.Conduit.Network as CN import Data.IORef ( newIORef, modifyIORef', readIORef) main :: IO () main = CN.runTCPClient (CN.clientSettings 5555 "192.168.2.11") client where logMsg cnt = CL.mapM $ \bs -> liftIO $ do modifyIORef' cnt (+ 1) readIORef cnt >>= \x -> putStrLn $ "msg #" ++ show x ++ " of size: " ++ show (BS.length bs) return bs client ad = do reader <- forkIO (runResourceT $ CN.appSource ad $$ CL.mapM_ ( \bs -> (liftIO . putStrLn) $ "read " ++ show (BS.length bs) ++ " bytes")) cnt <- newIORef ( 0 :: Int ) let runPipe = runResourceT $ CB.sourceFile "cool-linux-distro.iso" $$ logMsg cnt $= CN.appSink ad runPipe `finally` (killThread reader) }}} Having a `nc -l -p 5555 > /dev/null` running on another machine is sufficient to sink the data. Assuming that we can read `bigfile.iso` faster than we can send out over the socket, the `send` syscall will at some point give an `EAGAIN` as can be seen in the `truss` output: {{{ write(1,"msg #20 of size: 32752\n",23) = 23 (0x17) sendto(12,"\f\2409\0\M^RA\^T\M-&A\M-'\M-d8"...,32752,0x0,NULL,0x0) = 32752 (0x7ff0) read(13,"\M^?\0'\\\M-B\M-:+\^]D\M-0\M-="...,32752) = 32752 (0x7ff0) poll({ 1/POLLOUT },1,0) = 1 (0x1) msg #21 of size: 32752 write(1,"msg #21 of size: 32752\n",23) = 23 (0x17) sendto(12,"\M^?\0'\\\M-B\M-:+\^]D\M-0\M-="...,32752,0x0,NULL,0x0) = 19204 (0x4b04) sendto(12,"\M-j$2\M^BH\M-#-\^A\M-E\^O\M^Y\a"...,13548,0x0,NULL,0x0) ERR#35 'Resource temporarily unavailable' SIGNAL 26 (SIGVTALRM) sigprocmask(SIG_SETMASK,{ SIGVTALRM },0x0) = 0 (0x0) sigreturn(0x7fffffff9c60) ERR#35 'Resource temporarily unavailable' kevent(3,{ 12,EVFILT_READ,EV_ADD|EV_ONESHOT,0x0,0x0,0x0 },1,0x0,0,{ 0.000000000 }) = 0 (0x0) _umtx_op(0x800c71ed0,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x0,0x0) ERR#4 'Interrupted system call' SIGNAL 26 (SIGVTALRM) sigprocmask(SIG_SETMASK,{ SIGVTALRM },0x0) = 0 (0x0) sigreturn(0x7fffffffdc00) ERR#4 'Interrupted system call' _umtx_op(0x800c71ed0,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x0,0x0) ERR#4 'Interrupted system call' SIGNAL 26 (SIGVTALRM) }}} Not the `sendto` call on fd 12 resulting in `ERR#35`, soon followed by an `kevent` call for that same fd and only `EVFILT_READ` set. This makes little sense as it was an attempt to ''write'' that just failed. This is caused by `toFilter` giving precedence to `read` events, dropping the write event. Not starting the `reader` thread prevents bad things from happening as then the `write` events are properly passed thru to kqueue. I have an initial version of a patch fixing this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13903> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13554: Allow the user to provide a C function that is called on each thread the RTS creates before running any Haskell code
by GHC 13 Jan '18

13 Jan '18

#13554: Allow the user to provide a C function that is called on each thread the RTS creates before running any Haskell code -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Runtime | Version: 8.0.1 System | 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, it is very difficult to use the MySQL/MariaDB client library with Haskell. One must use bound threads, which comes at a performance penalty. The reason is that the underlying library requires a certain initialization function to be called on each OS thread before any other functions are called. Similarly, it is difficult to optimally use libcurl with GHC. The best- performing way to use libcurl is to have one multi handle per thread and to use `curl_multi_socket_action` to respond to events. This is currently not possible from Haskell, at least not easily. (There are other issues with using libcurl from Haskell; most notably libcurl’s event support makes heavy use of callbacks, which are slow, to tell the application which file descriptors to wait for. But that is a separate issue.) Setting milestone to 8.4.1 because I don’t think that this is difficult. This is a feature requ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13554> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14042: Data type with type family in return kind spuriously rejected
by GHC 07 Jan '18

07 Jan '18

#14042: Data type with type family in return kind spuriously rejected -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This typechecks: {{{#!hs {-# LANGUAGE TypeInType #-} import Data.Kind type Id (a :: Type) = a data Foo :: Id Type }}} But changing the type synonym to a type family causes it to fail: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} import Data.Kind type family Id (a :: Type) :: Type where Id a = a data Foo :: Id Type }}} {{{ $ ghci Foo.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Foo.hs, interpreted ) Foo.hs:9:1: error: • Kind signature on data type declaration has non-* return kind Id * • In the data declaration for ‘Foo’ | 9 | data Foo :: Id Type | ^^^^^^^^ }}} That error message is wrong, since `Id * = *`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14042> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #10245: panic in new integer switch logic with "out-of-range" literals
by GHC 07 Jan '18

07 Jan '18

#10245: panic in new integer switch logic with "out-of-range" literals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time Architecture: x86_64 | crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Compiling this module {{{ module D (f) where f :: Int -> String f n = case n of 0x8000000000000000 -> "yes" _ -> "no" }}} crashes with the error {{{ [1 of 1] Compiling D ( /tmp/D.hs, /tmp/D.o ) ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.11.20150403 for x86_64-unknown-linux): Map.findMin: empty map has no minimal element }}} The constant does not have to be exactly `0x8000000000000000`, everything I tested from there up to `0xffffffffffffffff` yields the same crash. Also occurs with `Word` and negative literals. The bug seems to be tied to the target's word size somehow, though: a 64-bit compiler does not panic on `Int32` and `0x80000000`, but a 32-bit compiler does. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10245> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #10731: System.IO.openTempFile is not thread safe on Windows
by GHC 04 Jan '18

04 Jan '18

#10731: System.IO.openTempFile is not thread safe on Windows -------------------------------------+------------------------------------- Reporter: | Owner: NeilMitchell | Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 libraries/base | Keywords: | Operating System: Windows Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Given the test program: {{{#!hs import Control.Concurrent import System.IO import Control.Monad import System.Directory main = do putStrLn "Starting" var <- newEmptyMVar tdir <- getTemporaryDirectory xs <- replicateM 10 $ do var <- newEmptyMVar flip forkFinally (\s -> do print s; putMVar var ()) $ do replicateM_ 100000 $ do (file, h) <- openTempFile tdir "test.txt" hClose h removeFile file return var mapM_ takeMVar xs }}} If I compile and run that with {{{ghc --make TmpFile.hs -threaded && tmpfile +RTS -N5}}} I get: {{{ Starting Left C:\Users\NDMIT_~1\AppData\Local\Temp\: openTempFile: permission denied (Permission denied) Left C:\Users\NDMIT_~1\AppData\Local\Temp\: openTempFile: permission denied (Permission denied) ... }}} I've reproduced this on GHC 7.8 and 7.10.1. We hit this in production about twice a day. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10731> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7