[m-rev.] for post-commit review and opinions: warn option classification

[Zoltan Somogyi]

On Mon, 19 May 2025 16:39:56 +1000, Peter Wang <novalazy at gmail.com> wrote:
> On Mon, 19 May 2025 16:39:03 +1000 Peter Wang <novalazy at gmail.com> wrote:
> > On Mon, 19 May 2025 16:33:05 +1000 Julien Fischer <jfischer at opturion.com> wrote:
> > > 
> > > We can abbreviate a little
> > > 
> > >    oc_warn_ctrl
> > >    oc_warn_correct
> > >    oc_warn_style
> > >    oc_inform
> > > 
> > > Even though oc_warn_correct is now the longest of the option_categroy
> > > constructors,
> > > it's now only by one letter.  (I'm tempted to rename oc_warn_correct
> > > to oc_warn_dodgy ...)
> > 
> > oc_warn_suspect?
> 
> Or indeed, "sus".

I am fine with any of oc_sus, oc_dodgy and oc_corr (short for correctness).
Whatever you pick, I will change to, *after* the diff I just posted for review
is committed (to avoid a conflict).

Does anyone object to replacing the existing functions that return the list
of style and nonstyle options, which have proven to be incomplete
with a call to solutions using the new subcategories? The only user visible
effect would be that fixing that incompleteness will turn off more warnings
in cases where we turn off either just style warnings, or "all" warnings
(which previously left some on.)

And does anyone object to turning off warnings when creating .*opt files?
Here, I can see arguments for both turning them off, and leaving them on.
Turning them off would mean that all warnings go into .err files, where
they are easy to see and to interpret as "this warning is for this module",
neither of which is true for the current system which puts warnings into
the stream of output from an invocation of mmake. On the other hand,
the current systems makes them "available" to the programmer
earlier. For me, since I don't tend to watch mmake output as it is made,
turning them off makes more sense. How about you?

Zoltan.