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

Julien Fischer jfischer at opturion.com
Sat Aug 16 16:43:31 AEST 2025


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.
(One of my pet irritations is compilers that emit warnings that they
do not provide
a way to shut up.)

> 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?

Julien.


More information about the developers mailing list