Comments, white space, and rename "InlineRule" to "stable unfolding"

The "InlineRule" is gone now, so this is just making the comments line
up with the code.  A function does change its name though:
   updModeForInlineRules  -->  updModeForStableUnfoldings

4 files changed, 44 insertions, 44 deletions

diff --git a/compiler/simplCore/OccurAnal.lhs b/compiler/simplCore/OccurAnal.lhs
index 6456eccd49..7a237c8764 100644
--- a/compiler/simplCore/OccurAnal.lhs
+++ b/compiler/simplCore/OccurAnal.lhs
@@ -625,13 +625,13 @@ data Details
   = ND { nd_bndr :: Id          -- Binder
        , nd_rhs  :: CoreExpr    -- RHS, already occ-analysed
 
-       , nd_uds  :: UsageDetails  -- Usage from RHS, and RULES, and InlineRule unfolding
+       , nd_uds  :: UsageDetails  -- Usage from RHS, and RULES, and stable unfoldings
                                   -- ignoring phase (ie assuming all are active)
                                   -- See Note [Forming Rec groups]
 
        , nd_inl  :: IdSet       -- Free variables of
-                                --   the InlineRule (if present and active)
-                                --   or the RHS (ir no InlineRule)
+                                --   the stable unfolding (if present and active)
+                                --   or the RHS (if not)
                                 -- but excluding any RULES
                                 -- This is the IdSet that may be used if the Id is inlined
 
@@ -1798,8 +1798,8 @@ tagLamBinders :: UsageDetails          -- Of scope
               -> (UsageDetails,        -- Details with binders removed
                  [IdWithOccInfo])    -- Tagged binders
 -- Used for lambda and case binders
--- It copes with the fact that lambda bindings can have InlineRule
--- unfoldings, used for join points
+-- It copes with the fact that lambda bindings can have a
+-- stable unfolding, used for join points
 tagLamBinders usage binders = usage' `seq` (usage', bndrs')
   where
     (usage', bndrs') = mapAccumR tag_lam usage binders
diff --git a/compiler/simplCore/SimplUtils.lhs b/compiler/simplCore/SimplUtils.lhs
index 941587c878..1cfba43c5e 100644
--- a/compiler/simplCore/SimplUtils.lhs
+++ b/compiler/simplCore/SimplUtils.lhs
@@ -14,7 +14,7 @@ module SimplUtils (
         preInlineUnconditionally, postInlineUnconditionally,
         activeUnfolding, activeRule,
         getUnfoldingInRuleMatch,
-        simplEnvForGHCi, updModeForInlineRules,
+        simplEnvForGHCi, updModeForStableUnfoldings,
 
         -- The continuation type
         SimplCont(..), DupFlag(..), 
@@ -542,9 +542,9 @@ simplEnvForGHCi dflags
    -- Do not do any inlining, in case we expose some unboxed
    -- tuple stuff that confuses the bytecode interpreter
 
-updModeForInlineRules :: Activation -> SimplifierMode -> SimplifierMode
--- See Note [Simplifying inside InlineRules]
-updModeForInlineRules inline_rule_act current_mode
+updModeForStableUnfoldings :: Activation -> SimplifierMode -> SimplifierMode
+-- See Note [Simplifying inside stable unfoldings]
+updModeForStableUnfoldings inline_rule_act current_mode
   = current_mode { sm_phase = phaseFromActivation inline_rule_act
                  , sm_inline = True
                  , sm_eta_expand = False }
@@ -572,10 +572,10 @@ Example of why (iii) is important:
 If we were to inline g into f's inlining, then an importing module would
 never be able to do
         f e --> g (g e) ---> RULE fires
-because the InlineRule for f has had g inlined into it.
+because the stable unfolding for f has had g inlined into it.
 
 On the other hand, it is bad not to do ANY inlining into an
-InlineRule, because then recursive knots in instance declarations
+stable unfolding, because then recursive knots in instance declarations
 don't get unravelled.
 
 However, *sometimes* SimplGently must do no call-site inlining at all
@@ -592,9 +592,9 @@ running it, we don't want to use -O2.  Indeed, we don't want to inline
 anything, because the byte-code interpreter might get confused about
 unboxed tuples and suchlike.
 
-Note [Simplifying inside InlineRules]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-We must take care with simplification inside InlineRules (which come from
+Note [Simplifying inside stable unfoldings]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+We must take care with simplification inside stable unfoldings (which come from
 INLINE pragmas).
 
 First, consider the following example
@@ -605,35 +605,35 @@ First, consider the following example
         in ...g...g...g...g...g...
 Now, if that's the ONLY occurrence of f, it might be inlined inside g,
 and thence copied multiple times when g is inlined. HENCE we treat
-any occurrence in an InlineRule as a multiple occurrence, not a single
+any occurrence in a stable unfolding as a multiple occurrence, not a single
 one; see OccurAnal.addRuleUsage.
 
-Second, we do want *do* to some modest rules/inlining stuff in InlineRules,
-partly to eliminate senseless crap, and partly to break the recursive knots
-generated by instance declarations.
+Second, we do want *do* to some modest rules/inlining stuff in stable
+unfoldings, partly to eliminate senseless crap, and partly to break
+the recursive knots generated by instance declarations.
 
 However, suppose we have
         {-# INLINE <act> f #-}
         f = <rhs>
 meaning "inline f in phases p where activation <act>(p) holds".
 Then what inlinings/rules can we apply to the copy of <rhs> captured in
-f's InlineRule?  Our model is that literally <rhs> is substituted for
+f's stable unfolding?  Our model is that literally <rhs> is substituted for
 f when it is inlined.  So our conservative plan (implemented by
-updModeForInlineRules) is this:
+updModeForStableUnfoldings) is this:
 
   -------------------------------------------------------------
-  When simplifying the RHS of an InlineRule, set the phase to the
-  phase in which the InlineRule first becomes active
+  When simplifying the RHS of an stable unfolding, set the phase
+  to the phase in which the stable unfolding first becomes active
   -------------------------------------------------------------
 
 That ensures that
 
   a) Rules/inlinings that *cease* being active before p will
-     not apply to the InlineRule rhs, consistent with it being
+     not apply to the stable unfolding, consistent with it being
      inlined in its *original* form in phase p.
 
   b) Rules/inlinings that only become active *after* p will
-     not apply to the InlineRule rhs, again to be consistent with
+     not apply to the stable unfolding, again to be consistent with
      inlining the *original* rhs in phase p.
 
 For example,
@@ -656,7 +656,7 @@ Similarly, consider
 and suppose that there are auto-generated specialisations and a strictness
 wrapper for g.  The specialisations get activation AlwaysActive, and the
 strictness wrapper get activation (ActiveAfter 0).  So the strictness
-wrepper fails the test and won't be inlined into f's InlineRule. That
+wrepper fails the test and won't be inlined into f's stable unfolding. That
 means f can inline, expose the specialised call to g, so the specialisation
 rules can fire.
 
@@ -819,7 +819,7 @@ let-float if you inline windowToViewport
 However, as usual for Gentle mode, do not inline things that are
 inactive in the intial stages.  See Note [Gentle mode].
 
-Note [InlineRule and preInlineUnconditionally]
+Note [Stable unfoldings and preInlineUnconditionally]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Surprisingly, do not pre-inline-unconditionally Ids with INLINE pragmas!
 Example
@@ -838,7 +838,7 @@ we'll lose the opportunity to inline at each of fInt's call sites.
 The INLINE pragma will only inline when the application is saturated
 for exactly this reason; and we don't want PreInlineUnconditionally
 to second-guess it.  A live example is Trac #3736.
-    c.f. Note [InlineRule and postInlineUnconditionally]
+    c.f. Note [Stable unfoldings and postInlineUnconditionally]
 
 Note [Top-level botomming Ids]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -860,7 +860,7 @@ preInlineUnconditionally :: DynFlags -> SimplEnv -> TopLevelFlag -> InId -> InEx
 --         for unlifted, side-effect-full bindings
 preInlineUnconditionally dflags env top_lvl bndr rhs
   | not active                               = False
-  | isStableUnfolding (idUnfolding bndr)     = False -- Note [InlineRule and preInlineUnconditionally]
+  | isStableUnfolding (idUnfolding bndr)     = False -- Note [Stable unfoldings and preInlineUnconditionally]
   | isTopLevel top_lvl && isBottomingId bndr = False -- Note [Top-level bottoming Ids]
   | not (gopt Opt_SimplPreInlining dflags)   = False
   | isCoVar bndr                             = False -- Note [Do not inline CoVars unconditionally]
@@ -976,7 +976,7 @@ postInlineUnconditionally dflags env top_lvl bndr occ_info rhs unfolding
   | isWeakLoopBreaker occ_info  = False -- If it's a loop-breaker of any kind, don't inline
                                         -- because it might be referred to "earlier"
   | isExportedId bndr           = False
-  | isStableUnfolding unfolding = False -- Note [InlineRule and postInlineUnconditionally]
+  | isStableUnfolding unfolding = False -- Note [Stable unfoldings and postInlineUnconditionally]
   | isTopLevel top_lvl          = False -- Note [Top level and postInlineUnconditionally]
   | exprIsTrivial rhs           = True
   | otherwise
@@ -1069,12 +1069,12 @@ ones that are trivial):
 
   * The inliner should inline trivial things at call sites anyway.
 
-Note [InlineRule and postInlineUnconditionally]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Do not do postInlineUnconditionally if the Id has an InlineRule, otherwise
-we lose the unfolding.  Example
+Note [Stable unfoldings and postInlineUnconditionally]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Do not do postInlineUnconditionally if the Id has an stable unfolding,
+otherwise we lose the unfolding.  Example
 
-     -- f has InlineRule with rhs (e |> co)
+     -- f has stable unfolding with rhs (e |> co)
      --   where 'e' is big
      f = e |> co
 
@@ -1083,10 +1083,10 @@ Then there's a danger we'll optimise to
      f' = e
      f = f' |> co
 
-and now postInlineUnconditionally, losing the InlineRule on f.  Now f'
+and now postInlineUnconditionally, losing the stable unfolding on f.  Now f'
 won't inline because 'e' is too big.
 
-    c.f. Note [InlineRule and preInlineUnconditionally]
+    c.f. Note [Stable unfoldings and preInlineUnconditionally]
 
 
 %************************************************************************
diff --git a/compiler/simplCore/Simplify.lhs b/compiler/simplCore/Simplify.lhs
index 49c86a1c19..09a2befe97 100644
--- a/compiler/simplCore/Simplify.lhs
+++ b/compiler/simplCore/Simplify.lhs
@@ -780,8 +780,8 @@ simplUnfolding env top_lvl id new_rhs unf
     bottoming = isBottomingId id
     is_top_lvl = isTopLevel top_lvl
     act      = idInlineActivation id
-    rule_env = updMode (updModeForInlineRules act) env
-               -- See Note [Simplifying inside InlineRules] in SimplUtils
+    rule_env = updMode (updModeForStableUnfoldings act) env
+               -- See Note [Simplifying inside stable unfoldings] in SimplUtils
 \end{code}
 
 Note [Force bottoming field]
@@ -824,9 +824,9 @@ Note [Setting the new unfolding]
   important: if exprIsConApp says 'yes' for a recursive thing, then we
   can get into an infinite loop
 
-If there's an InlineRule on a loop breaker, we hang on to the inlining.
-It's pretty dodgy, but the user did say 'INLINE'.  May need to revisit
-this choice.
+If there's an stable unfolding on a loop breaker (which happens for
+INLINEABLE), we hang on to the inlining.  It's pretty dodgy, but the
+user did say 'INLINE'.  May need to revisit this choice.
 
 Note [Setting the demand info]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -2568,7 +2568,7 @@ An alternative plan is this:
 but that is bad if 'c' is *not* later scrutinised.
 
 So instead we do both: we pass 'c' and 'c#' , and record in c's inlining
-(an InlineRule) that it's really I# c#, thus
+(a stable unfolding) that it's really I# c#, thus
 
    $j = \c# -> \c[=I# c#] -> ...c....
 
diff --git a/compiler/stranal/WorkWrap.lhs b/compiler/stranal/WorkWrap.lhs
index ef2fb53aa6..81bce8c97c 100644
--- a/compiler/stranal/WorkWrap.lhs
+++ b/compiler/stranal/WorkWrap.lhs
@@ -148,8 +148,8 @@ The only reason this is monadised is for the unique supply.
 Note [Don't w/w INLINE things]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 It's very important to refrain from w/w-ing an INLINE function (ie one
-with an InlineRule) because the wrapper will then overwrite the
-InlineRule unfolding.
+with a stable unfolding) because the wrapper will then overwrite the
+old stable unfolding with the wrapper code.
 
 Furthermore, if the programmer has marked something as INLINE,
 we may lose by w/w'ing it.