June 2016 - ghc-tickets

[GHC] #10793: Incorrect blocked on MVar detection
by GHC 02 Oct '18

02 Oct '18

#10793: Incorrect blocked on MVar detection -------------------------------------+------------------------------------- Reporter: | Owner: simonmar NeilMitchell | Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.1 System | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Given the code: {{{#!hs import Control.Concurrent main = do v <- newEmptyMVar forkFinally (putStrLn $ let x = x in x) (putMVar v) print =<< takeMVar v }}} The spawned thread should raise a {{{NonTermination}}} exception (assuming idle GC), then put it in the MVar {{{v}}}, which should cause the main thread to abort printing {{{Left <<loop>>}}}. However, in reality, the main thread aborts with {{{Exception: thread blocked indefinitely in an MVar operation}}}. My debugging shows that the spawned thread raises {{{NonTermination}}} and at the same time the main thread raises {{{BlockedIndefinitelyOnMVar}}}. Of course, the main thread is not really blocked on the exception, and after the finally bit runs, the MVar is filled. Adding tracing shows that the {{{putMVar}}} is called. Hypothesis is that the GC notices it can raise the non-termination exception, and then opportunistically excludes that thread from further GC scanning, and detects the MVar is unreferenced, raising the subsequent exception. Of course, given you can catch the exception, that isn't safe. Roman Leshchinskiy worries that in the wrong circumstances the MVar might really be being GC'd and thus could corrupt memory. This issue was detected while debugging an error in the Shake build system for GHC itself. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10793> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12146: syntax repair suggestion is too eager to suggest TemplateHaskell
by GHC 01 Oct '18

01 Oct '18

#12146: syntax repair suggestion is too eager to suggest TemplateHaskell -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- On input `ipmort Data.Monoid`, ghc's suggestion is {{{ Parse error: naked expression at top level Perhaps you intended to use TemplateHaskell }}} Apart from the nudity: the suggestion is unreasonable for beginners, and unnecessary for experts. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12146> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #8226: Remove the old style -- # Haddock comments.
by GHC 01 Oct '18

01 Oct '18

#8226: Remove the old style -- # Haddock comments. ------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Haddock 0.x supported -- # style comments for Haddock pragma and while this seems to have been long forgotten and not documented, it's still kicking in the lexer. I think this is a good time to get rid of these all together. Relevant Haddock ticket http://trac.haskell.org/haddock/ticket/171 I'll hopefully send in patches removing these from the lexer/parser tomorrow, if all goes well (unless anyone feels eager to do it, then please, you're most welcome to do so!). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8226> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11498: GHC requires kind-polymorphic signatures on class head
by GHC 01 Oct '18

01 Oct '18

#11498: GHC requires kind-polymorphic signatures on class head -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2-rc2 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: -------------------------------------+------------------------------------- I have the following compiling example: {{{ {-# LANGUAGE DataKinds, FlexibleContexts, FlexibleInstances, KindSignatures, MultiParamTypeClasses, PolyKinds, RankNTypes, ScopedTypeVariables, TypeFamilies, TypeOperators #-} import Data.Proxy import GHC.Prim type family CtxOf d (args :: k) :: Constraint class Run ctx (params :: [k]) where runAll :: Proxy params -> Proxy ctx -> (forall (args :: k) . (CtxOf ctx args) => Proxy args -> Bool) -> [Bool] data BasicCtxD type instance CtxOf BasicCtxD '(a,b) = (a ~ b) instance (Run BasicCtxD params, a ~ b) => Run BasicCtxD ( '(a,b) ': params) where runAll _ pctx f = (f (Proxy::Proxy '(a,b))) : (runAll (Proxy::Proxy params) pctx f) }}} But if I move the kind signature of `params` to its occurrence in the signature of `runAll`: {{{ class Run ctx params where runAll :: Proxy (params :: [k]) -> Proxy ctx -> (forall (args :: k) . (CtxOf ctx args) => Proxy args -> Bool) -> [Bool] }}} I get a couple of nasty (and confusing) compile errors. {{{ Main.hs:20:25: Couldn't match kind ‘k1’ with ‘(,) k k’ ‘k1’ is a rigid type variable bound by the type signature for runAll :: Proxy ('(a, b) : params) -> Proxy BasicCtxD -> (forall (args :: k1). CtxOf BasicCtxD args => Proxy args -> Bool) -> [Bool] at Main.hs:20:3 Expected type: Proxy args0 Actual type: Proxy '(a, b) Relevant bindings include f :: forall (args :: k1). CtxOf BasicCtxD args => Proxy args -> Bool (bound at Main.hs:20:17) runAll :: Proxy ('(a, b) : params) -> Proxy BasicCtxD -> (forall (args :: k1). CtxOf BasicCtxD args => Proxy args -> Bool) -> [Bool] (bound at Main.hs:20:3) In the first argument of ‘f’, namely ‘(Proxy :: Proxy '(a, b))’ In the first argument of ‘(:)’, namely ‘(f (Proxy :: Proxy '(a, b)))’ In the expression: (f (Proxy :: Proxy '(a, b))) : (runAll (Proxy :: Proxy params) pctx f) Main.hs:21:42: Could not deduce (k1 ~ (,) k k) from the context (CtxOf BasicCtxD args) bound by a type expected by the context: CtxOf BasicCtxD args => Proxy args -> Bool at Main.hs:21:8-42 ‘k1’ is a rigid type variable bound by the type signature for runAll :: Proxy ('(a, b) : params) -> Proxy BasicCtxD -> (forall (args :: k1). CtxOf BasicCtxD args => Proxy args -> Bool) -> [Bool] at Main.hs:20:3 Expected type: Proxy args -> Bool Actual type: Proxy args1 -> Bool Relevant bindings include f :: forall (args :: k1). CtxOf BasicCtxD args => Proxy args -> Bool (bound at Main.hs:20:17) runAll :: Proxy ('(a, b) : params) -> Proxy BasicCtxD -> (forall (args :: k1). CtxOf BasicCtxD args => Proxy args -> Bool) -> [Bool] (bound at Main.hs:20:3) In the third argument of ‘runAll’, namely ‘f’ In the second argument of ‘(:)’, namely ‘(runAll (Proxy :: Proxy params) pctx f)’ }}} It seems to me that the two definitions of the class are equivalent, so it would be nice if they both compiled. It wasn't obvious to me that the kind signature had to go on the class parameter rather than somewhere else. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11498> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10986: GHC should delete all temporary files it creates in /tmp
by GHC 30 Sep '18

30 Sep '18

#10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 creates large numbers of temporary files in /tmp. These would normally get cleaned up when the machine is rebooted, but for things like Jenkins build machines that don't get rebooted often they buld up pretty quickly. The /tmp on my Jenkins build machine currently has over 200k files and directories, but only about 40 of them are non-GHC related files. Under normal operation, GHC should delete all temporary files it creates. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10986> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #11955: Haddock documentation for pattern synonyms printed with explicit forall quantifiers
by GHC 29 Sep '18

29 Sep '18

#11955: Haddock documentation for pattern synonyms printed with explicit forall quantifiers -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc3 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: -------------------------------------+------------------------------------- Running haddock on: {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Foo ( A(..), pattern P ) where data A a = A a pattern P :: a -> A a pattern P a <- A a }}} in GHC 7.10.3 gives haddock documentation for P in the form of: {{{ pattern P :: a -> A a }}} while the haddock in GHC 8.0.1-rc3 gives haddock documentation for P in the form of: {{{ pattern P :: forall a. a -> A a }}} I think GHC/Haddock should not be adding the forall quantifier, and hence think the behaviour in GHC 8.0.1-rc3 is wrong, and the behaviour of GHC 7.10.3 is preferred. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11955> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent)
by GHC 29 Sep '18

29 Sep '18

#8400: Migrate the RTS to use libuv (or libev, or libevent) ----------------------------------------------+---------------------------- Reporter: schyler | Owner: Type: feature request | simonmar Priority: normal | Status: new Component: Runtime System | Milestone: Keywords: | Version: Architecture: Unknown/Multiple | Operating System: Difficulty: Project (more than a week) | Unknown/Multiple Blocked By: | Type of failure: Related Tickets: 635, 7353 | None/Unknown | Test Case: | Blocking: ----------------------------------------------+---------------------------- This is mainly a reference discussion ticket. libuv (https://github.com/joyent/libuv) is a lightweight library which allows asynchronous IO across OpenBSD, Linux, Darwin, Windows etc by utilizing the fastest implementation on each system (epoll, kqueue, IOCP, event ports). These specialized IO polling methods are '''much''' faster on their respective platforms than just using select() like the RTS currently does. Additionally, it also provides cross platform threads, mutex, condition vars, terminal input/output and term settings w/ cross platform ANSI escape code handling, thread pools, cross platform HRC's etc. It's currently significantly faster than libevent and slightly faster than libev (and no doubt faster than rolling our own stuff). Because it's maintained and utilized heavily by Node.js it's in extremely active and maintained development. Rewriting a portion of the RTS to utilize libuv would have the following benefits; * We could ditch basically all of our platform specific code. Everything under rts/win32 and rts/posix, except the SEH stuff, could be deleted. * libuv is tuned for speed on each platform. This would be an optimization to all our async IO stuff. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8400> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 29

[GHC] #12178: Allow inline pragmas on pattern synonyms
by GHC 28 Sep '18

28 Sep '18

#12178: Allow inline pragmas on pattern synonyms -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Richard observes that it might be useful to allow inline pragmas to refer to pattern synonyms to ensure that the matcher is inlined. The main question to resolve is whether `{-# INLINE P #-}` means to inline just the matcher, just the builder or both. It seems that without more fine grained control then the pragma should cause both the matcher and builder to be inline but I am not certain about this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12178> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8809: Prettier error messages?
by GHC 27 Sep '18

27 Sep '18

#8809: Prettier error messages? ------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- `clang` has very nice-looking error messages. {{{ #!html <pre>pretty.c:6:7: warning: incompatible pointer to integer conversion passing 'char [14]' to parameter of type 'int' [-Wint-conversion] foo("Hello, world!"); ^~~~~~~~~~~~~~~ pretty.c:1:14: note: passing argument to parameter 'i' here void foo(int i) { ^ 1 warning generated.</pre> }}} `ghc`'s error messages are not so good. {{{ #!html <pre>ugly.hs:7:18: Couldn't match expected type ‘()’ with actual type ‘[Char]’ In the first argument of ‘f’, namely ‘"Hello, world!"’ In the second argument of ‘($)’, namely ‘f "Hello, world!"’ In the expression: print $ f "Hello, world!"</pre> }}} In my opinion, there are three independent improvements that could be made to GHC error messages and warnings: color, context and whitespace. Currently they're blobs of text. Consider all three applied to error messages: {{{ #!html <pre>ugly.hs:7:18: error: Argument to 'f' is type '[Char]' but expected 'Int' main = print $ f "Hello, world!" ^~~~~~~~~~~~~~~ ugly.hs:3:1: note: type of 'f' is given here: f :: () -> IO () ^~</pre> }}} or {{{ #!html <pre>ugly.hs: note: type of 'f' is inferred: f :: forall m. Monad m => () -> m () ^~</pre> }}} In my opinion, context and whitespace are more important that color. Even without color, compare this error message to the one shown above: {{{ ugly.hs:7:18: error: Argument to 'f' is type '[Char]' but expected 'Int' main = print $ f "Hello, world!" ^~~~~~~~~~~~~~~ ugly.hs:3:1: note: type of 'f' is given here: f :: () -> IO () ^~ }}} In my opinion this is much easier to visually process than GHC's current messages. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8809> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 79

[GHC] #10990: Checking whether a default declaration is an instance of a defaultable typeclass is broken
by GHC 26 Sep '18

26 Sep '18

#10990: Checking whether a default declaration is an instance of a defaultable typeclass is broken -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | 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: -------------------------------------+------------------------------------- In TcDefaults.hs, `tcDefaults` is supposed to check whether the supplied default type is an instance o `Num` or `IsString` (note the lack of extended defaults here, so this has been broken for quite some time). Following the code we can see that `simplifyDefault` in TcSimplify.hs calls `reportAllUnsolved` and it does report the error -- with typechecker tracing on we see {{{ Adding error: <interactive>:19:1: error: No instance for (Num []) arising from a 'default' declaration When checking the types in a default declaration }}} But typechecking never actually fails, so it returns `Just ()` regardless and the error gets swallowed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10990> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3