#14850: mallocBytes allows underflow
-------------------------------------+-------------------------------------
Reporter: wyager | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone:
Component: | Version: 8.0.2
libraries/base |
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: Poor/confusing
Unknown/Multiple | error message
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
https://hackage.haskell.org/package/base-4.10.1.0/docs/src/Foreign.Marshal.…
This function doesn't complain when passed a negative number. Instead you
get something like
`*** Exception: malloc: resource exhausted (out of memory)`
Which is confusing, and probably not consistent across platforms.
This came up in https://github.com/tel/saltine/issues/42
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14850>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#14839: Bits typeclass law for LSB
-------------------------------------+-------------------------------------
Reporter: andrewthad | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 8.2.2
Keywords: base | Operating System: Unknown/Multiple
Architecture: | Type of failure: None/Unknown
Unknown/Multiple |
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
The documentation for the `Bits` typeclass claims:
> Bits are numbered from 0 with bit 0 being the least significant bit.
However, there's no law specified in the typeclass that enforces this. I
realized this recently because I've been adding the laws for `Bits` to a
library of property tests I maintain: http://hackage.haskell.org/package
/quickcheck-classes-0.3.3/docs/Test-QuickCheck-Classes.html#v:bitsLaws
In another package of mine, someone requested to add a `Bits` instance for
a type but with the MSB considered bit 0. (https://github.com/andrewthad
/haskell-ip/issues/29) I thought this would fail to satisfy a law of
`Bits`, but it doesn't. So at the least, I was thinking we could add the
following laws to `FiniteBits`:
{{{
countTrailingZeros (bit 0) = 0
countLeadingZeros (bit 0) = finiteBitSize undefined - 1
}}}
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14839>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#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 sgraf):
This is what I have so far:
[https://github.com/sgraf812/ghc/compare/8529fbba309cd692bbbb0386321515d05a6…
#diff-992f9a53caac96c0e6303669d68a20e1 diff]
The reason why I couldn't find the lambda's free vars in the `ValueEnv`
earlier is that the matching
[https://github.com/sgraf812/ghc/compare/8529fbba309cd692bbbb0386321515d05a6…
#diff-992f9a53caac96c0e6303669d68a20e1R2140 argToPat case] didn't add them
before. That's a problem for our specific case, where the free vars of the
lambda are bound within the call-pattern, e.g. `Just (let x = 4 in \y. x +
y)`.
With that fix in place, the free var values are detected just fine and
guided by the `ConVal` case I could implement the
[https://github.com/sgraf812/ghc/compare/8529fbba309cd692bbbb0386321515d05a6…
#diff-992f9a53caac96c0e6303669d68a20e1R2180 specialisation code]. From
what I can tell, the generated specialisation looks great, but it isn't
called anywhere because now the rules no longer fire.
My particular solution would just introduce let bindings into the lambda
body that re-bind things we find to be values (similar to how arguments of
a data con are handled). Example:
{{{
let {
lvl_s4md = *# sc_s4rb sc_s4rb
lvl_s4lL = I# lvl_s4md
lvl_s4ll = Yield @ Bool @ Int False lvl_s4lL } in
MkStream
@ Int
@ Bool
(\ (ds_d2Fz :: Bool) ->
case ds_d2Fz of {
False -> Stop @ Bool @ Int;
True -> lvl_s4ll
})
True
==>
let {
lvl_s4md = *# sc_s4rb sc_s4rb
lvl_s4lL = I# lvl_s4md
lvl_s4ll = Yield @ Bool @ Int False lvl_s4lL } in
MkStream
@ Int
@ Bool
(\ (ds_d2Fz :: Bool) ->
let {
lvl_s4ll = Yield @ Bool @ Int False (I# sc_s4md) } in
case ds_d2Fz of {
False -> Stop @ Bool @ Int;
True -> lvl_s4ll
})
True
}}}
Kind-of a manual float-in of all bindings we know are values and have
corresponding `ScrutOcc` (which we ignore at the moment).
This results in a much better specialisation for `Just (MkStream <lam>
True)` I believe (`dump-simpl`):
{{{
$s$wgo_s4rg :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# ->
GHC.Prim.Int#
$s$wgo_s4rg (sc_s4rf :: GHC.Prim.Int#)
(sc1_s4re :: GHC.Prim.Int#)
(sc2_s4rd :: GHC.Prim.Int#)
= jump $wgo_s4ph
GHC.Types.SPEC
(GHC.Prim.+# sc2_s4rd sc_s4rf)
sc1_s4re
(GHC.Base.Just
@ (Stream Int)
(Main.MkStream
@ Int
@ Bool
(\ (ds_d2Fz :: Bool) ->
case ds_d2Fz of {
False -> Main.Stop @ Bool @ Int;
True ->
Main.Yield @ Bool @ Int GHC.Types.False (GHC.Types.I#
sc_s4rf)
})
GHC.Types.False));
}}}
There's a problem though: That function doesn't get called any more,
because the corresponding RULE looks like this:
{{{
"SC:$wgo2" [0]
forall (sc_s4rj :: GHC.Prim.Int#)
(sc_s4rk :: Bool)
(sc_s4ri :: GHC.Prim.Int#)
(sc_s4rh :: GHC.Prim.Int#).
$wgo_s4ph GHC.Types.SPEC
sc_s4rh
sc_s4ri
(GHC.Base.Just
@ (Stream Int)
(Main.MkStream
@ Int
@ Bool
(\ (ds_d2Fz :: Bool) ->
let {
sc_s4rf :: GHC.Prim.Int#
[LclId]
sc_s4rf = sc_s4rj } in
let {
lvl_s4ll :: Step Bool Int
[LclId]
lvl_s4ll
= Main.Yield
@ Bool
@ Int
GHC.Types.False
(GHC.Types.I# sc_s4rf) } in
case ds_d2Fz of {
False -> Main.Stop @ Bool @ Int;
True -> lvl_s4ll
})
sc_s4rk))
= jump $s$wgo_s4rr sc_s4rj sc_s4rk sc_s4ri sc_s4rh
}}}
E.g. the extra bindings I introduced obstruct the RULE engine. I can
probably figure out how to generate the right rules tomorrow.
Please yell if I'm missing some critical pass or function to do this!
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/855#comment:17>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#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 RyanGlScott):
Hm. I suppose you could add the original program from this ticket:
{{{#!hs
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE QuantifiedConstraints #-}
{-# LANGUAGE UndecidableInstances #-}
module T5927 where
data Exists c where Exists :: c a => a -> Exists c
instance (forall a. c a => Show a) => Show (Exists c) where
show (Exists a) = show a
}}}
But this actually fails!
{{{
Bug.hs:9:10: error:
• Could not deduce: c (Exists c)
arising from a use of ‘GHC.Show.$dmshowsPrec’
from the context: forall a. c a => Show a
bound by the instance declaration at Bug.hs:9:10-53
• In the expression: GHC.Show.$dmshowsPrec @(Exists c)
In an equation for ‘showsPrec’:
showsPrec = GHC.Show.$dmshowsPrec @(Exists c)
In the instance declaration for ‘Show (Exists c)’
• Relevant bindings include
showsPrec :: Int -> Exists c -> ShowS (bound at Bug.hs:9:10)
|
9 | instance (forall a. c a => Show a) => Show (Exists c) where
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Bug.hs:9:10: error:
• Could not deduce: c (Exists c)
arising from a use of ‘GHC.Show.$dmshowList’
from the context: forall a. c a => Show a
bound by the instance declaration at Bug.hs:9:10-53
• In the expression: GHC.Show.$dmshowList @(Exists c)
In an equation for ‘showList’:
showList = GHC.Show.$dmshowList @(Exists c)
In the instance declaration for ‘Show (Exists c)’
• Relevant bindings include
showList :: [Exists c] -> ShowS (bound at Bug.hs:9:10)
|
9 | instance (forall a. c a => Show a) => Show (Exists c) where
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
}}}
I'm not sure what to make of this. If you implement `showsPrec` and
`showList` manually:
{{{#!hs
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE QuantifiedConstraints #-}
{-# LANGUAGE UndecidableInstances #-}
module T5927 where
import Text.Show
data Exists c where Exists :: c a => a -> Exists c
instance (forall a. c a => Show a) => Show (Exists c) where
show (Exists a) = show a
showsPrec p (Exists a) = showsPrec p a
showList l = showListWith (\(Exists a) -> shows a) l
}}}
Then it typechecks.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5927#comment:32>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#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 sgraf):
Thanks for your insights! I have to read up on defunctionalisation, but
what you suggest is basically what I had in mind in 1. above: Query the
free variables of the lambda and see if they are in the
[https://github.com/sgraf812/ghc/commit/c6c9fbe1eb5ad117b5bd23e943c82ca7bc23…
#diff-992f9a53caac96c0e6303669d68a20e1R2163 ValueEnv] (meaning their RHSs
are in WHNF, too). For some reason they weren't present where I expected
them, looking into this now.
>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.
Well, I'm not sure we can see that without running some kind of
simplification first. But with `SPEC`, the matching `ArgOcc` is
irrelevant, so we can look into this later. I
[https://github.com/sgraf812/ghc/commit/c6c9fbe1eb5ad117b5bd23e943c82ca7bc23…
#diff-992f9a53caac96c0e6303669d68a20e1R1144 conveniently left] `CallOcc`
with an `ArgOcc` field for when the result of the call is scrutinised for
that.
I'll go and see if I can get the free vars of the lambda into the
`ValueEnv`.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/855#comment:16>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#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
#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
#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
#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
#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
