+activeRule :: DynFlags -> SimplEnv -> Maybe (Activation -> Bool)
+-- Nothing => No rules at all
+activeRule dflags env
+ | not (dopt Opt_EnableRewriteRules dflags)
+ = Nothing -- Rewriting is off
+ | otherwise
+ = case getMode env of
+ SimplGently { sm_rules = rules_on }
+ | rules_on -> Just isEarlyActive -- Note [RULEs enabled in SimplGently]
+ | otherwise -> Nothing
+ SimplPhase n _ -> Just (isActive n)
+\end{code}
+
+--------------------------------------------------------------
+ OLD NOTES, now wrong
+ Preserved just for now (Oct 10)
+--------------------------------------------------------------
+
+ OK, so 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 when it is inlined. So our conservative plan (implemented by
+ updModeForInlineRules) is this:
+
+ -------------------------------------------------------------
+ When simplifying the RHS of an InlineRule,
+ If the InlineRule becomes active in phase p, then
+ if the current phase is *earlier than* p,
+ make no inlinings or rules active when simplifying the RHS
+ otherwise
+ set the phase to p when simplifying the RHS
+
+ -- Treat Gentle as phase "infinity"
+ -- If current_phase `earlier than` inline_rule_start_phase
+ -- then no_op
+ -- else
+ -- if current_phase `same phase` inline_rule_start_phase
+ -- then current_phase (keep gentle flags)
+ -- else inline_rule_start_phase
+ -------------------------------------------------------------
+
+ That ensures that
+
+ a) Rules/inlinings that *cease* being active before p will
+ not apply to the InlineRule rhs, 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
+ inlining the *original* rhs in phase p.
+
+ For example,
+ {-# INLINE f #-}
+ f x = ...g...
+
+ {-# NOINLINE [1] g #-}
+ g y = ...
+
+ {-# RULE h g = ... #-}
+ Here we must not inline g into f's RHS, even when we get to phase 0,
+ because when f is later inlined into some other module we want the
+ rule for h to fire.
+
+ Similarly, consider
+ {-# INLINE f #-}
+ f x = ...g...
+
+ g y = ...
+ 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
+ means f can inline, expose the specialised call to g, so the specialisation
+ rules can fire.
+
+--------------------------------------------------------------
+ END OF OLD NOTES
+--------------------------------------------------------------