Comments about ru_auto

...following a question from Conal

compiler/coreSyn/CoreSyn.hs

@@ -864,15 +864,16 @@ data CoreRule
                                         -- See Note [OccInfo in unfoldings and rules]
 
         -- Locality
-        ru_auto :: Bool,        -- ^ @True@  <=> this rule is auto-generated
-                                --   @False@ <=> generated at the users behest
-                                --   Main effect: reporting of orphan-hood
+        ru_auto :: Bool,   -- ^ @True@  <=> this rule is auto-generated
+                           --               (notably by Specialise or SpecConstr)
+                           --   @False@ <=> generated at the users behest
+                           -- See Note [Trimming auto-rules] in TidyPgm
+                           -- for the sole purpose of this field.
 
-        ru_origin :: !Module,    -- ^ 'Module' the rule was defined in, used
+        ru_origin :: !Module,   -- ^ 'Module' the rule was defined in, used
                                 -- to test if we should see an orphan rule.
 
-        ru_orphan :: !IsOrphan,
-                                -- ^ Whether or not the rule is an orphan.
+        ru_orphan :: !IsOrphan, -- ^ Whether or not the rule is an orphan.
 
         ru_local :: Bool        -- ^ @True@ iff the fn at the head of the rule is
                                 -- defined in the same module as the rule

compiler/main/TidyPgm.hs

@@ -887,9 +887,13 @@ reference to f_spec except from the RULE.
 
 Now that RULE *might* be useful to an importing module, but that is
 purely speculative, and meanwhile the code is taking up space and
-codegen time.  So is seeems better to drop the binding for f_spec if
-the auto-generated rule is the *only* reason that it is being kept
-alive.
+codegen time.  I found that binary sizes jumped by 6-10% when I
+started to specialise INLINE functions (again, Note [Inline
+specialisations] in Specialise).
+
+So it seeems better to drop the binding for f_spec, and the rule
+itself, if the auto-generated rule is the *only* reason that it is
+being kept alive.
 
 (The RULE still might have been useful in the past; that is, it was
 the right thing to have generated it in the first place.  See Note
@@ -902,12 +906,10 @@ So findExternalRules does this:
   * Remove all auto rules that mention bindings that have been removed
       (this is done by filtering by keep_rule)
 
-So if a binding is kept alive for some *other* reason (e.g. f_spec is
+NB: if a binding is kept alive for some *other* reason (e.g. f_spec is
 called in the final code), we keep the rule too.
 
-I found that binary sizes jumped by 6-10% when I started to specialise
-INLINE functions (again, Note [Inline specialisations] in Specialise).
-Adding trimAutoRules removed all this bloat.
+This stuff is the only reason for the ru_auto field in a Rule.
 -}
 
 findExternalRules :: Bool       -- Omit pragmas