...
 
Commits (5)
# Configure git to ignore commits listed in this file with:
#
# git config blame.ignoreRevsFile .git-ignore-revs
# Module Hierarchy Renamings
af332442123878c1b61d236dce46418efcbe8750
255418da5d264fb2758bc70925adb2094f34adc3
1941ef4f050c0dfcb68229641fcbbde3a10f1072
528df8ecb4e2f9c78b1ae4ab7ff8230644e9b643
18a346a4b5a02b8c62e8eedb91b35c2d8e754b96
817f93eac4d13f680e8e3e7a25eb403b1864f82e
1b1067d14b656bbbfa7c47f156ec2700c9751549
240f5bf6f53515535be5bf3ef7632aa69ae21e3e
1500f0898e85316c7c97a2f759d83278a072ab0e
3ca52151881451ce5b3a7740d003e811b586140d
cf739945b8b28ff463dc44925348f20b3c1f22cb
da7f74797e8c322006eba385c9cbdce346dd1d43
6e2d9ee25bce06ae51d2f1cf8df4f7422106a383
d491a6795d507eabe35d8aec63c534d29f2d305b
99a9f51bf8207c79241fc0b685fadeb222a61292
eb6082358cdb5f271a8e4c74044a12f97352c52f
5119296440e6846c553c72b8a93afc5ecfa576f0
447864a94a1679b5b079e08bb7208a0005381cef
......@@ -830,6 +830,21 @@ Ticks into the LHS, which makes matching trickier. #10665, #10745.
Doing this to either side confounds tools like HERMIT, which seek to reason
about and apply the RULES as originally written. See #10829.
There is, however, one case where we are pretty much /forced/ to transform the
LHS of a rule: postInlineUnconditionally. For instance, in the case of
let f = g @Int in f
We very much want to inline f into the body of the let. However, to do so (and
be able to safely drop f's binding) we must inline into all occurrences of f,
including those in the LHS of rules.
This can cause somewhat surprising results; for instance, in #18162 we found
that a rule template contained ticks in its arguments, because
postInlineUnconditionally substituted in a trivial expression that contains
ticks. See Note [Tick annotations in RULE matching] in GHC.Core.Rules for
details.
Note [No eta expansion in stable unfoldings]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If we have a stable unfolding
......@@ -1251,6 +1266,10 @@ it's best to inline it anyway. We often get a=E; b=a from desugaring,
with both a and b marked NOINLINE. But that seems incompatible with
our new view that inlining is like a RULE, so I'm sticking to the 'active'
story for now.
NB: unconditional inlining of this sort can introduce ticks in places that
may seem surprising; for instance, the LHS of rules. See Note [Simplfying
rules] for details.
-}
postInlineUnconditionally
......
......@@ -714,11 +714,15 @@ match :: RuleMatchEnv
-> CoreExpr -- Target
-> Maybe RuleSubst
-- We look through certain ticks. See note [Tick annotations in RULE matching]
-- We look through certain ticks. See Note [Tick annotations in RULE matching]
match renv subst e1 (Tick t e2)
| tickishFloatable t
= match renv subst' e1 e2
where subst' = subst { rs_binds = rs_binds subst . mkTick t }
match renv subst (Tick t e1) e2
-- Ignore ticks in rule template.
| tickishFloatable t
= match renv subst e1 e2
match _ _ e@Tick{} _
= pprPanic "Tick in rule" (ppr e)
......@@ -1016,7 +1020,7 @@ Hence, (a) the guard (not (isLocallyBoundR v2))
Note [Tick annotations in RULE matching]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We used to unconditionally look through Notes in both template and
We used to unconditionally look through ticks in both template and
expression being matched. This is actually illegal for counting or
cost-centre-scoped ticks, because we have no place to put them without
changing entry counts and/or costs. So now we just fail the match in
......@@ -1025,6 +1029,11 @@ these cases.
On the other hand, where we are allowed to insert new cost into the
tick scope, we can float them upwards to the rule application site.
Moreover, we may encounter ticks in the template of a rule. There are a few
ways in which these may be introduced (e.g. #18162, #17619). Such ticks are
ignored by the matcher. See Note [Simplifying rules] in
GHC.Core.Opt.Simplify.Utils for details.
cf Note [Notes in call patterns] in GHC.Core.Opt.SpecConstr
Note [Matching lets]
......
This diff is collapsed.
......@@ -59,7 +59,7 @@ import GHC.Types.Basic ( pprRuleName, TypeOrKind(..) )
import GHC.Data.FastString
import GHC.Types.SrcLoc as SrcLoc
import GHC.Driver.Session
import GHC.Utils.Misc ( debugIsOn, filterOut, lengthExceeds, partitionWith )
import GHC.Utils.Misc ( debugIsOn, lengthExceeds, partitionWith )
import GHC.Driver.Types ( HscEnv, hsc_dflags )
import GHC.Data.List.SetOps ( findDupsEq, removeDups, equivClasses )
import GHC.Data.Graph.Directed ( SCC, flattenSCC, flattenSCCs, Node(..)
......@@ -664,7 +664,9 @@ rnClsInstDecl (ClsInstDecl { cid_poly_ty = inst_ty, cid_binds = mbinds
rnFamInstEqn :: HsDocContext
-> AssocTyFamInfo
-> [Located RdrName] -- Kind variables from the equation's RHS
-> [Located RdrName]
-- ^ Kind variables from the equation's RHS to be implicitly bound
-- if no explicit forall.
-> FamInstEqn GhcPs rhs
-> (HsDocContext -> rhs -> RnM (rhs', FreeVars))
-> RnM (FamInstEqn GhcRn rhs', FreeVars)
......@@ -683,20 +685,36 @@ rnFamInstEqn doc atfi rhs_kvars
-- Use the "...Dups" form because it's needed
-- below to report unused binder on the LHS
-- Implicitly bound variables, empty if we have an explicit 'forall'.
-- See Note [forall-or-nothing rule] in GHC.Rename.HsType.
; let imp_vars = nubL $ forAllOrNothing (isJust mb_bndrs) pat_kity_vars_with_dups
; imp_var_names <- mapM (newTyVarNameRn mb_cls) imp_vars
; let bndrs = fromMaybe [] mb_bndrs
bnd_vars = map hsLTyVarLocName bndrs
payload_kvars = filterOut (`elemRdr` (bnd_vars ++ imp_vars)) rhs_kvars
-- Make sure to filter out the kind variables that were explicitly
-- bound in the type patterns.
; payload_kvar_names <- mapM (newTyVarNameRn mb_cls) payload_kvars
-- all names not bound in an explicit forall
; let all_imp_var_names = imp_var_names ++ payload_kvar_names
-- all_imp_vars represent the implicitly bound type variables. This is
-- empty if we have an explicit `forall` (see
-- Note [forall-or-nothing rule] in GHC.Rename.HsType), which means
-- ignoring:
--
-- - pat_kity_vars_with_dups, the variables mentioned in the LHS of
-- the equation, and
-- - rhs_kvars, the kind variables mentioned in an outermost kind
-- signature on the RHS of the equation. (See
-- Note [Implicit quantification in type synonyms] in
-- GHC.Rename.HsType for why these are implicitly quantified in the
-- absence of an explicit forall).
--
-- For example:
--
-- @
-- type family F a b
-- type instance forall a b c. F [(a, b)] c = a -> b -> c
-- -- all_imp_vars = []
-- type instance F [(a, b)] c = a -> b -> c
-- -- all_imp_vars = [a, b, c]
-- @
; all_imp_vars <- forAllOrNothing (isJust mb_bndrs) $
-- No need to filter out explicit binders (the 'mb_bndrs = Just
-- explicit_bndrs' case) because there must be none if we're going
-- to implicitly bind anything, per the previous comment.
nubL $ pat_kity_vars_with_dups ++ rhs_kvars
; all_imp_var_names <- mapM (newTyVarNameRn mb_cls) all_imp_vars
-- All the free vars of the family patterns
-- with a sensible binding location
......@@ -2096,14 +2114,14 @@ rnConDecl decl@(ConDeclGADT { con_names = names
-- That order governs the order the implicitly-quantified type
-- variable, and hence the order needed for visible type application
-- See #14808.
free_tkvs = extractHsTvBndrs explicit_tkvs $
extractHsTysRdrTyVarsDups (theta ++ arg_tys ++ [res_ty])
; implicit_bndrs <- forAllOrNothing explicit_forall
$ extractHsTvBndrs explicit_tkvs
$ extractHsTysRdrTyVarsDups (theta ++ arg_tys ++ [res_ty])
ctxt = ConDeclCtx new_names
; let ctxt = ConDeclCtx new_names
mb_ctxt = Just (inHsDocContext ctxt)
; traceRn "rnConDecl" (ppr names $$ ppr free_tkvs $$ ppr explicit_forall )
; rnImplicitBndrs (forAllOrNothing explicit_forall free_tkvs) $ \ implicit_tkvs ->
; rnImplicitBndrs implicit_bndrs $ \ implicit_tkvs ->
bindLHsTyVarBndrs ctxt mb_ctxt Nothing explicit_tkvs $ \ explicit_tkvs ->
do { (new_cxt, fvs1) <- rnMbContext ctxt mcxt
; (new_args, fvs2) <- rnConDeclDetails (unLoc (head new_names)) ctxt args
......
......@@ -1136,10 +1136,11 @@ Haddock
single: haddock
.. ghc-flag:: -haddock
:shortdesc: Make the parser more strict about Haddock comments.
:shortdesc: With this flag GHC will parse Haddock comments and include them
in the interface file it produces.
:type: dynamic
:reverse: -no-haddock
:category: misc
:category: haddock
By default, GHC ignores Haddock comments (``-- | ...`` and ``-- ^ ...``)
and does not check that they're associated with a valid term, such as a
......
Subproject commit 8fffea5ca319e85e1bc9e7cac39e5a2c8effefcc
Subproject commit 1afc36ecd38c069251a836e1c1c8b3a3043ddc01
{-# LANGUAGE ExplicitForAll #-}
{-# LANGUAGE TypeApplications #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE DataKinds #-}
module T18145 where
type family A :: k
type instance forall. A = Nothing :: Maybe a -- 'a' should be out of scope
class Foo x where
type B x :: Maybe a
type forall x. B x = Nothing :: Maybe a -- 'a' should be out of scope
instance Foo [x] where
type forall. B [x] = Nothing :: Maybe a -- 'a' should be out of scope
T18145.hs:10:44: error: Not in scope: type variable ‘a’
T18145.hs:14:41: error: Not in scope: type variable ‘a’
T18145.hs:17:41: error: Not in scope: type variable ‘a’
......@@ -153,3 +153,4 @@ test('T16504', normal, compile_fail, [''])
test('T14548', normal, compile_fail, [''])
test('T16610', normal, compile_fail, [''])
test('T17593', normal, compile_fail, [''])
test('T18145', normal, compile_fail, [''])