April 2015 - ghc-tickets

[GHC] #10124: Simple case analyses generate too many branches
by GHC 20 Apr '15

20 Apr '15

#10124: Simple case analyses generate too many branches -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Take the following example, {{{#!hs f :: Int -> Bool f a = case a of 1 -> True 5 -> True 8 -> True 9 -> True 11 -> True 19 -> True _ -> False {-# NOINLINE f #-} main = print $ f 8 }}} This gets lowered to the following Core (by GHC 7.8), {{{#!hs f f = \ a_s3EH -> case a_s3EH of _ { I# ds_s3EJ -> case ds_s3EJ of _ { __DEFAULT -> False; 1 -> True; 5 -> True; 8 -> True; 9 -> True; 11 -> True; 19 -> True } } }}} I have expected GHC to lower this into a nice string of logical operations, with perhaps a couple of branches at the end to determine the result. Unfortunately, this is not what happens. Instead the C-- is a sea of branches, {{{ c3F7: _s3EK::I64 = I64[R1 + 7]; if (%MO_S_Lt_W64(_s3EK::I64, 9)) goto c3Fz; else goto c3FA; c3Fz: if (%MO_S_Lt_W64(_s3EK::I64, 5)) goto c3Fq; else goto c3Fr; c3Fq: if (_s3EK::I64 != 1) goto c3Ff; else goto c3Fg; c3Fr: if (%MO_S_Lt_W64(_s3EK::I64, 8)) goto c3Fn; else goto c3Fo; c3Fn: if (_s3EK::I64 != 5) goto c3Ff; else goto c3Fg; c3Fo: if (_s3EK::I64 != 8) goto c3Ff; else goto c3Fg; c3FA: if (%MO_S_Lt_W64(_s3EK::I64, 11)) goto c3Fw; else goto c3Fx; c3Fw: if (_s3EK::I64 != 9) goto c3Ff; else goto c3Fg; c3Fx: if (%MO_S_Lt_W64(_s3EK::I64, 19)) goto c3Ft; else goto c3Fu; c3Ft: if (_s3EK::I64 != 11) goto c3Ff; else goto c3Fg; c3Fu: if (_s3EK::I64 != 19) goto c3Ff; else goto c3Fg; c3Ff: R1 = False_closure+1; Sp = Sp + 8; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; c3Fg: R1 = True_closure+2; Sp = Sp + 8; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; ... }}} Which gets turned into the branchy assembler that you would expect. To my surprise even the LLVM backend isn't able to bring this back into a branchless form. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10124> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #10326: ImpredicativeTypes: Unable to use in Functor etc..
by GHC 20 Apr '15

20 Apr '15

#10326: ImpredicativeTypes: Unable to use in Functor etc.. -------------------------------------+------------------------------------- Reporter: | Owner: j80JjBjVNRMajmA | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I want to use values of RankNTypes within Functors/Monads/... just like normal values. The following code shows, that I cannot lift a function `ReturnNull -> ReturnNull` into a functor the way I would like to (e.g. `liftId2`). However, using another version that seems equivalent and that is allowed by GHC, `liftId3`, does not allow me to pipe the result to `override`. How can I do this? {{{#!hs {-# LANGUAGE ImpredicativeTypes #-} type ReturnNull = forall m. Monad m => m () id2 :: ReturnNull -> ReturnNull id2 = id testId2 :: ReturnNull testId2 = id2 $ return () liftId :: Functor f => f ReturnNull -> f ReturnNull liftId = fmap id -- rejected liftId2 :: Functor f => f ReturnNull -> f ReturnNull liftId2 = fmap id2 liftId3 :: (Monad m,Functor f) => f ReturnNull -> f (m ()) liftId3 = fmap id2 override :: Functor f => f ReturnNull -> f () override = fmap $ const () testLift :: Functor f => f ReturnNull -> f () testLift = override . liftId --rejected testLift3 :: Functor f => f ReturnNull -> f () testLift3 = override . liftId3 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10326> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #6089: Allow declaration splices inside declaration brackets
by GHC 20 Apr '15

20 Apr '15

#6089: Allow declaration splices inside declaration brackets -------------------------------------+------------------------------------- Reporter: igloo | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): The renamer splices and then typechecks now, so we should be able to do this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6089#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2041: Allow splicing in concrete syntax
by GHC 20 Apr '15

20 Apr '15

#2041: Allow splicing in concrete syntax -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Template Haskell | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): This ticket was discussed here: https://ghc.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal#PartD:q… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2041#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4372: Accept expressions in left-hand side of quasiquotations (was: Extending quasiquotation support)
by GHC 20 Apr '15

20 Apr '15

#4372: Accept expressions in left-hand side of quasiquotations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Renamed to something more descriptive. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4372#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2041: Allow splicing in concrete syntax
by GHC 20 Apr '15

20 Apr '15

#2041: Allow splicing in concrete syntax -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Template Haskell | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): The feature as stated here is rather conservatively stated, but in a more generalized form it could greatly improve the usability of Template Haskell. Basically, you are asking for proper quote/antiquote (antiquotes are nested splices.) There's a few ways this could be implemented: 1. (Original String) As this ticket suggests, a new constructor is defined which contains bits of concrete syntax. When, converting from the TH representation to GHC representation, the GHC parser is invoked to convert syntax into concrete representation. 2. (Monadic String) Alternately, some new methods could be added to the Quasi monad, which is the "hook" interface that allows template-haskell to call into GHC's code. These methods would like in the Q monad. This has the benefit of letting us error out early if syntax is not well-formed. 3. (ghc-api) We could make splices accept proper `ghc` AST returns, in which case we skip the TH conversion pass. In this case, a user could just directly call out to the ghc-api to parse syntax, and then that could be inserted into the TH splcie. 4. (Parser) Introduce a new syntactic form for quotation (something like quasi-quote syntax? quasi-quote with a special sigil?); contents of the quotation are parsed by the parser. Some tricky stuff happens. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2041#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10255: API Annotations : ExprWithTySig processing discards annotated spans
by GHC 20 Apr '15

20 Apr '15

#10255: API Annotations : ExprWithTySig processing discards annotated spans -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: Other ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In `RdrHsSyn.checkAPat` the processing for `ExprWithTySig` is defined as {{{#!hs ExprWithTySig e t _ -> do e <- checkLPat msg e -- Pattern signatures are parsed as sigtypes, -- but they aren't explicit forall points. Hence -- we have to remove the implicit forall here. let t' = case t of L _ (HsForAllTy Implicit _ _ (L _ []) ty) -> ty other -> other return (SigPatIn e (mkHsWithBndrs t')) }}} The `t'` variable ends up losing its original SrcSpan in the first case branch. This results in annotations becoming detached from the AST. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10255> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7430: GHC API reports CPP errors in confusing ways
by GHC 20 Apr '15

20 Apr '15

#7430: GHC API reports CPP errors in confusing ways -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: GHC API | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Should be possible to construct a small example? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7430#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7695: Hang when locale-archive and gconv-modules are not there
by GHC 20 Apr '15

20 Apr '15

#7695: Hang when locale-archive and gconv-modules are not there -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: None | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8977 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Oh, do you mean #10298? Indeed it looks the same. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7695#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7695: Hang when locale-archive and gconv-modules are not there
by GHC 20 Apr '15

20 Apr '15

#7695: Hang when locale-archive and gconv-modules are not there -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: None | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8977 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * priority: normal => highest * milestone: 7.12.1 => 7.10.2 Comment: Let's get this one fixed, Michael Snoyman recently ran into an issue that sounds like the same thing when working with Docker. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7695#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0