- ghc-tickets - Haskell.org

[GHC] #10791: Add a --disable-large-memory-space configure option
by GHC 02 Oct '18

02 Oct '18

#10791: Add a --disable-large-memory-space configure option -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature | Status: new request | Priority: normal | Milestone: 7.12.1 Component: Build | Version: 7.11 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- GHC recently started using large (1TB) address space on 64 bit systems. This feature is enabled by default but does not work on arm64-linux or amd64-solaris. Even just for testing, it would be nice to be able to disable this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10791> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15699: Run sanity checker in more testsuite runs
by GHC 02 Oct '18

02 Oct '18

#15699: Run sanity checker in more testsuite runs -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Continuous | Version: 8.4.3 Integration | 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: -------------------------------------+------------------------------------- Every testsuite run should run at least a subset of tests with the sanity checker enabled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15699> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15697: Typed holes inferring a more polymorphic type
by GHC 02 Oct '18

02 Oct '18

#15697: Typed holes inferring a more polymorphic type -------------------------------------+------------------------------------- Reporter: sreenidhi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Consider these two snippets. {{{#!hs testFailure :: Char testFailure = let x = id _ in x }}} Suggestions provided were {{{ /home/sreenidhi/Experiments/TypedHole.hs:3:14: error: • Found hole: _ :: a Where: ‘a’ is a rigid type variable bound by the inferred type of x :: a at /home/sreenidhi/Experiments/TypedHole.hs:3:7-14 • In the first argument of ‘id’, namely ‘_’ In the expression: id _ In an equation for ‘x’: x = id _ • Relevant bindings include x :: a (bound at /home/sreenidhi/Experiments/TypedHole.hs:3:7) testFailure :: Char (bound at /home/sreenidhi/Experiments/TypedHole.hs:2:1) }}} whereas for this one {{{#!hs testSuccess :: Char testSuccess = _ }}} It correctly suggests {{{ /home/sreenidhi/Experiments/TypedHole.hs:7:15: error: • Found hole: _ :: Char • In the expression: _ In an equation for ‘testSuccess’: testSuccess = _ • Relevant bindings include testSuccess :: Char (bound at /home/sreenidhi/Experiments/TypedHole.hs:7:1) Valid hole fits include testSuccess :: Char (bound at /home/sreenidhi/Experiments/TypedHole.hs:7:1) testFailure :: Char (defined at /home/sreenidhi/Experiments/TypedHole.hs:2:1) maxBound :: forall a. Bounded a => a with maxBound @Char (imported from ‘Prelude’ at /home/sreenidhi/Experiments/TypedHole.hs:1:1 (and originally defined in ‘GHC.Enum’)) minBound :: forall a. Bounded a => a with minBound @Char (imported from ‘Prelude’ at /home/sreenidhi/Experiments/TypedHole.hs:1:1 (and originally defined in ‘GHC.Enum’)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15697> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #7535: Using -with-rtsopts=-N should fail unless -threaded is also specified
by GHC 02 Oct '18

02 Oct '18

#7535: Using -with-rtsopts=-N should fail unless -threaded is also specified -------------------------------------+------------------------------------- Reporter: mhoermann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 4243 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): The problem is `-with-rtsopts` is really dumb, it just puts whatever you pass to it in a file which is linked with the program to provide the options to the RTS. It does not do any checks on the input. For example, `-with-rtsopts=-blah-blah` is also accepted. Ideally I guess the compiler would have access to RTS argument parsers for all RTS variants, and check with the parser of the correct RTS variant (e.g. when building prof+debug way it would use the prof+debug runtime's parser). It seems like too much work and it's not clear whether the added complexity (for having access to RTS parsers in the compiler) would worth it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7535#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2940: Do CSE after CorePrep
by GHC 02 Oct '18

02 Oct '18

#2940: Do CSE after CorePrep -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.10.1 Resolution: fixed | Keywords: CSE Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9291 | Differential Rev(s): Phab:D2871 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => closed * differential: => Phab:D2871 * resolution: => fixed * related: => #9291 Comment: We now do CSE after CorePrep (in STG). Closing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2940#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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] #15287: T11627[ab] fail on some Darwin environments
by GHC 02 Oct '18

02 Oct '18

#15287: T11627[ab] fail on some Darwin environments -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- As of d6216443c61cee94d8ffc31ca8510a534d9406b9 I am seeing `T11627a` and `T11627b` fail in the `prof_hr` way on Darwin under CircleCI (but not Harbormaster!): {{{ Wrong exit code for T11627b(prof_hr)(expected 0 , actual 139 ) Stderr ( T11627b ): /bin/sh: line 1: 73247 Segmentation fault: 11 ./T11627b +RTS -hr -RTS +RTS -i0 -RTS *** unexpected failure for T11627b(prof_hr) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15287> 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