February 2018 - ghc-tickets

Re: [GHC] #855: Improvements to SpecConstr
by GHC 26 Feb '18

26 Feb '18

#855: Improvements to SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: 915 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Another way of thinking about: thing in terms of defunctionalisation. Consider this higher order function {{{ let f :: (Int -> Bool) -> Int -> Char f g x = ....(g e)... in ...(f (\x.y+x)).... (f (\v.v*p*q))....(f h)... }}} Now defunctionalise by making a version of `f` that takes a data structure as its argument: {{{ data G_Fun = G1 Int -- \x.y+x | G2 Int Int -- \v.v*p*q | G3 (Int->Int) -- Escape hatch applyG :: G_Fun -> Int -> Bool applyG (G1 x) = \x.y+x applyG (G2 p q) = \v.v*p*q in ...(g e)... applyG (G3 g) = g let f' :: G_Fun -> Int -> Char f' ga x = ...(applyG ga e)... in ...(f' (G1 x))...(f' (G2 p q))...(f' (G3 h)) }}} (I guess you could do this via a w/w kind of transformation, but for now it's purely hypothetical.) Now we are back in the land of data-constructors, where `SpecConstr` thrives. Suppose the call is actually {{{ ...(f' (G1 (Yield e1 e2 e3)))... }}} Should we specialise on `(G1 x)` or on the deeper pattern `(G1 (Yield a b c))`? It depends how much `f'` scrutinises its argument. And you can see that from what `applyG` does. I think you could follow all this reasoning without ''actually'' createing `G_Fun` etc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/855#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #855: Improvements to SpecConstr
by GHC 26 Feb '18

26 Feb '18

#855: Improvements to SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: 915 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Include call-pattern specialisation in the Simplifier, for a radical change I'm not keen on this * The Simplifier and `SpecConstr` are both very complex passes. Combining them would be ... difficult. * `SpecConstr` relies on a pretty elaborate form of occurrence analysis, which I'm not sure we'd want to replicated in the simplifier. Let's be really sure that nothing else will work first. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/855#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5927: A type-level "implies" constraint on Constraints
by GHC 26 Feb '18

26 Feb '18

#5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | Keywords: Resolution: duplicate | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2893 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Are there any test cases from this ticket that we can add as regression tests for #2983? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5927#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11107: Can't use type wildcard infix
by GHC 25 Feb '18

25 Feb '18

#11107: Can't use type wildcard infix -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- This fails: {{{ foo :: Int `_a` Bool foo = Right True }}} But moving `_a` to be prefix works. I observe the same behavior with an unnamed type wildcard. This was discovered while poking around in the renamer, not in real code! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11107> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13088: Type operator holes don't work infix
by GHC 25 Feb '18

25 Feb '18

#13088: Type operator holes don't work infix -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #13050 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Originally noted in https://phabricator.haskell.org/D2910 (which fixed #13050). Currently, you can do this: Does this also work with TypeOperators? That is, you can do this: {{{#!hs {-# LANGUAGE TypeOperators #-} foo :: a `_over` b -> _over a b foo = id }}} But not this: {{{#!hs {-# LANGUAGE TypeOperators #-} foo :: a `_` b -> over a b foo = id }}} osa1 made an attempt at fixing this, and recorded his progress [https://phabricator.haskell.org/D2910#85423 here]: > I played with alternative implementations and attempted at implementing type-level version of this patch as suggested by @RyanGlScott. > > Since `_` needs special treatment by the renamer I think we have to have some kind of special treatment for `_` in the parser too, so this implementation may not be too bad. > > (alternatively I guess we could remove special treatment for `_` in the parser but that'd just move special cases to the renamer, so I'm not sure that's any better than the current approach) > > About the type-level named infix holes: Type renamer is quite different than term renamer (`RnTypes.hs`) and I don't understand type-checker parts of the compiler -- but I was able to made an attempt at implementing this > > {{{#!diff > diff --git a/compiler/hsSyn/HsTypes.hs b/compiler/hsSyn/HsTypes.hs > index 53f200f..877c243 100644 > --- a/compiler/hsSyn/HsTypes.hs > +++ b/compiler/hsSyn/HsTypes.hs > @@ -608,6 +608,7 @@ type LHsAppType name = Located (HsAppType name) > data HsAppType name > = HsAppInfix (Located name) -- either a symbol or an id in backticks > | HsAppPrefix (LHsType name) -- anything else, including things like (+) > + | HsAppWild (Located (HsWildCardInfo name)) > deriving instance (DataId name) => Data (HsAppType name) > > instance (OutputableBndrId name) => Outputable (HsAppType name) where > @@ -987,11 +988,18 @@ getAppsTyHead_maybe tys = case splitHsAppsTy tys of > splitHsAppsTy :: [LHsAppType name] -> ([[LHsType name]], [Located name]) > splitHsAppsTy = go [] [] [] > where > + go :: [LHsType name] > + -> [[LHsType name]] > + -> [Located name] > + -> [LHsAppType name] > + -> ([[LHsType name]], [Located name]) > go acc acc_non acc_sym [] = (reverse (reverse acc : acc_non), reverse acc_sym) > go acc acc_non acc_sym (L _ (HsAppPrefix ty) : rest) > = go (ty : acc) acc_non acc_sym rest > go acc acc_non acc_sym (L _ (HsAppInfix op) : rest) > = go [] (reverse acc : acc_non) (op : acc_sym) rest > + go acc acc_non acc_sym (L l (HsAppWild (L _ wc)) : rest) > + = go (L l (HsWildCardTy wc) : acc) acc_non acc_sym rest > > -- Retrieve the name of the "head" of a nested type application > -- somewhat like splitHsAppTys, but a little more thorough > @@ -1334,14 +1342,18 @@ ppr_fun_ty ctxt_prec ty1 ty2 > > -------------------------- > ppr_app_ty :: (OutputableBndrId name) => TyPrec -> HsAppType name -> SDoc > -ppr_app_ty _ (HsAppInfix (L _ n)) = pprInfixOcc n > +ppr_app_ty _ (HsAppInfix (L _ n)) > + = pprInfixOcc n > ppr_app_ty _ (HsAppPrefix (L _ (HsTyVar NotPromoted (L _ n)))) > = pprPrefixOcc n > ppr_app_ty _ (HsAppPrefix (L _ (HsTyVar Promoted (L _ n)))) > = space <> quote (pprPrefixOcc n) -- We need a space before the ' above, so > -- the parser does not attach it to the > -- previous symbol > -ppr_app_ty ctxt (HsAppPrefix ty) = ppr_mono_lty ctxt ty > +ppr_app_ty ctxt (HsAppPrefix ty) > + = ppr_mono_lty ctxt ty > +ppr_app_ty ctxt (HsAppWild (L _ (AnonWildCard _))) > + = empty -- FIXME > > -------------------------- > ppr_tylit :: HsTyLit -> SDoc > diff --git a/compiler/parser/Parser.y b/compiler/parser/Parser.y > index dfb6755..da4696a 100644 > --- a/compiler/parser/Parser.y > +++ b/compiler/parser/Parser.y > @@ -1833,6 +1833,7 @@ tyapp :: { LHsAppType RdrName } > [mj AnnSimpleQuote $1] } > | SIMPLEQUOTE varop {% ams (sLL $1 $> $ HsAppInfix $2) > [mj AnnSimpleQuote $1] } > + | '`' '_' '`' { sL1 $1 (HsAppWild (sL1 $1 (AnonWildCard PlaceHolder))) } > > atype :: { LHsType RdrName } > : ntgtycon { sL1 $1 (HsTyVar NotPromoted $1) } -- Not including unit tuples > diff --git a/compiler/rename/RnTypes.hs b/compiler/rename/RnTypes.hs > index f3fcf88..9298020 100644 > --- a/compiler/rename/RnTypes.hs > +++ b/compiler/rename/RnTypes.hs > @@ -1050,8 +1050,11 @@ collectAnonWildCards lty = go lty > > gos = mconcat . map go > > + prefix_types_only :: HsAppType Name -> Maybe (LHsType Name) > prefix_types_only (HsAppPrefix ty) = Just ty > prefix_types_only (HsAppInfix _) = Nothing > + prefix_types_only (HsAppWild (L l (AnonWildCard wc_name))) = > + Just (L l (HsWildCardTy (AnonWildCard wc_name))) > > collectAnonWildCardsBndrs :: [LHsTyVarBndr Name] -> [Name] > collectAnonWildCardsBndrs ltvs = concatMap (go . unLoc) ltvs > @@ -1646,8 +1649,9 @@ extract_apps t_or_k tys acc = foldrM (extract_app t_or_k) acc tys > > extract_app :: TypeOrKind -> LHsAppType RdrName -> FreeKiTyVars > -> RnM FreeKiTyVars > -extract_app t_or_k (L _ (HsAppInfix tv)) acc = extract_tv t_or_k tv acc > -extract_app t_or_k (L _ (HsAppPrefix ty)) acc = extract_lty t_or_k ty acc > +extract_app t_or_k (L _ (HsAppInfix tv)) acc = extract_tv t_or_k tv acc > +extract_app t_or_k (L _ (HsAppPrefix ty)) acc = extract_lty t_or_k ty acc > +extract_app t_or_k (L _ (HsAppWild (L l wc))) acc = extract_lty t_or_k (L l (HsWildCardTy wc)) acc > > extract_hs_tv_bndrs :: [LHsTyVarBndr RdrName] -> FreeKiTyVars > -> FreeKiTyVars -> RnM FreeKiTyVars > }}} > > Once I figure out how to do the `FIXME` part this patch may just work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13088> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14762: Foreign.Marshal.Pool functions use inefficient O(n) operations
by GHC 25 Feb '18

25 Feb '18

#14762: Foreign.Marshal.Pool functions use inefficient O(n) operations -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.2.2 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `Foreign.Marshal.Pool` uses `Data.List.delete` and `Data.List.elem` to determine whether a pointer is already in the pool and to delete them, as a result of `newtype Pool = Pool (IORef [Ptr ()])`. Thus repeated operations on pools with many entries can become very slow. If possible, we might consider using `Ord` on the `Ptr` and an O(log n) data structure instead of a `[Ptr]` list. Alternatively, we should warn in the docs that this is the case, but it seems better to just fix the implementation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14762> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14853: Implement the "Semigroup and Monoid instances in Data.Functor.Product and friends" proposal
by GHC 25 Feb '18

25 Feb '18

#14853: Implement the "Semigroup and Monoid instances in Data.Functor.Product and friends" proposal -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: | Version: 8.2.2 libraries/base | 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: -------------------------------------+------------------------------------- https://mail.haskell.org/pipermail/libraries/2018-February/028570.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14853> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14852: Implement the "Eq1, Ord1, Read1, Show1 instances in GHC.Generics" proposal
by GHC 25 Feb '18

25 Feb '18

#14852: Implement the "Eq1, Ord1, Read1, Show1 instances in GHC.Generics" proposal -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: | Version: 8.2.2 libraries/base | 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: -------------------------------------+------------------------------------- https://mail.haskell.org/pipermail/libraries/2018-February/028570.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14852> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11777: RTS source code issues
by GHC 25 Feb '18

25 Feb '18

#11777: RTS source code issues -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Tiago Silva <tiagosilva(a)hush.com> writes: Last night I started looking at the C files used in GHC and noticed these issues: {{{ /driver/utils/cwrapper.c : int main(int, char **); }}} `void *p` is apparently unused, even if the compiler optimizes it away.. you should check if something went missing. {{{ /rts/RetainerProfile.c : static nat sanityCheckHeapClosure(StgClosure *) }}} `StgInfoTable *info` has the same issue as above {{{ /rts/RetainerSet.c #elif defined(RETAINER_SCHEME_CC) // Retainer scheme 3: retainer = cost centre void printRetainerSetShort(FILE *f, RetainerSet *rs, nat max_length) { char tmp[max_length + 1]; int size; nat j; } }}} Unlike the other functions around it, this function does nothing. Its variables are also not unused? {{{ /rts/sm/MarkWeak.c : void markWeakPtrList (void); if (w->header.info == &stg_DEAD_WEAK_info) { last_w = &(w->link); } else { last_w = &(w->link); } }}} Not sure what's going on here. Regardless of the test the two branches do the same thing. {{{ /rts/win32/IOManager.c : AddIORequest, AddDelayRequest, AddProcRequest functions }}} If `(!ioMan || !wItem)` the functions either return 0 or FALSE, but they don't free `wItem` before. Is this optimized by the compiler? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11777> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #14851: "Pattern match has inaccessible right hand side" with TypeRep
by GHC 25 Feb '18

25 Feb '18

#14851: "Pattern match has inaccessible right hand side" with TypeRep -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- When I say {{{#!hs {-# LANGUAGE PatternSynonyms, ViewPatterns #-} module Bug where import Type.Reflection pattern X arg <- (checkFun -> arg) checkFun :: TypeRep fun -> a checkFun = undefined f x = case (x, True) of (X _, _) -> 5 _ -> 6 g x = case x of (X _) -> 5 _ -> 6 }}} I get {{{ Bug.hs:13:11: warning: [-Woverlapping-patterns] Pattern match has inaccessible right hand side In a case alternative: (X _, _) -> ... | 13 | (X _, _) -> 5 | ^^^^^^^^^^^^^ }}} I'm troubled by two things: 1. There's nothing inaccessible about my right-hand side. 2. This happens only for `f`, not `g`. If there's no tuple, there's no problem. Note that this problems requires `TypeRep`. Even another polykinded tycon (like `Proxy`) didn't trigger the problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14851> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1