[m-dev.] warnings/purity_warningsn and mmc -w

[Zoltan Somogyi]

On Sat, 16 Aug 2025 16:43:31 +1000, Julien Fischer <jfischer at opturion.com> wrote:

> On Sat, 16 Aug 2025 at 02:13, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> >
> > I was just checking the operation of -w (--inhibit-warnings)
> > while working on the user guide, and I saw that this test case
> > generates the same set of warnings with and without -w.
> > The reason for this is that these warnings are generated by code
> > that does not depend on the values of the options that -w disables.
> >
> > There are two ways we can fix this, if indeed we want to fix it.
> > I do want to fix it, because the current situation violates the
> > law of least astonishment.
> >
> > Way 1: simply search for all occurrences of severity_warning
> > in the compiler, and ensure that every piece of code that constructs
> > such an error_spec tests the value of a oc_warn_* category option.
> >
> > Way 2: make --inhibit-warnings a plain option, and have write_error_spec.m
> > filter out every error_spec whose severity ends up being severity_warning
> > if it is set.
> >
> > Way 2 is in a way more robust, because it does not require constant
> > vigilance against the addition of new warnings that do not depend
> > on a warning option.
> 
> We should treat any warnings that do not depend on a warning option as a bug.

Agreed. I was trying to fix that bug not just for now, but also in way that
prevents it coming back later.

> > However, since write_error_spec cannot tell
> > whether a warning is a style warning or not, Way 1 cannot implement
> > --inhibit-STYLE-warnings.
> 
> Why would --inhibit-style-warnings not just imply turning off all of
> the style warnings?

It does do that now, and that sentence says I don't think we can change it.
In other words, you have nothing to worry about on this score.

But I just thought of a way to ensure that this bug gets fixed, and *stays* fixed.

First, add a subtype of option that consists of just the boolean warning options,
i.e. all the bool options in the oc_warn_* categories. Add another subtype for
just the bool options in the oc_inform category.

Next, modify the error_severity type by adding to the severity_warning function
symbol an argument of the first subtype above, and to the severity_informational
function symbol an argument of the second subtype. This would make all error_specs
of these severities implicitly conditional on the option named in the argument.

I am sure that this would require adding new options, e.g. for controlling the
warnings now output for the purity_warnings test case, and we will probably
go back and forth over their names.

Can anyone see a flaw in this plan? Does anyone have a better plan?

Zoltan.