bug#44746: 28.0.50; [feature/native-comp] Noisy "*Warnings*" buffer shown on start

[Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Stefan Kangas <stefan@marxist.se> writes:

> Every time I start Emacs after recompilation or clearing cache, I see a
> "*Warnings*" buffer popup in a new window, filled with a large amount of
> warnings like these:
>
> Warning (comp): debian-ispell.el:229:17: Warning: assignment to free
> variable Disable showing Disable logging
> Warning (comp): debian-ispell.el:228:28: Warning: reference to free
> variable ‘really-hunspell’ Disable showing Disable logging
> Warning (comp): debian-ispell.el:386:16: Warning: reference to free
> variable Disable showing Disable logging
> Warning (comp): debian-ispell.el:392:16: Warning: reference to free
> variable Disable showing Disable logging
> Warning (comp): debian-ispell.el:393:16: Warning: reference to free
> variable Disable showing Disable logging
> Warning (comp): debian-ispell.el:403:24: Warning: assignment to free
> variable Disable showing Disable logging
> Warning (comp): debian-ispell.el:403:20: Warning: reference to free
> variable Disable showing Disable logging
> [...]
> Warning (comp): init-general.el:44:7: Warning: assignment to free
> variable Disable showing Disable logging
> Warning (comp): init-general.el:45:7: Warning: assignment to free
> variable Disable showing Disable logging
> Warning (comp): init-general.el:47:7: Warning: assignment to free
> variable ‘Man-width’ Disable showing Disable logging
> [...]
>
> (The file init-general.el is required from my init file.)
>
> To reproduce this, I would assume it is sufficient to either run Debian,
> where the debian-ispell.el file is part of the site-files, or having an
> init file requiring a file with, for example, the line:
>
>     (setq display-time-24hr-format t) ; my line 47 above
>
>
> I'm not exactly sure what the best course of action is here.  But
> wouldn't it be better to not show this at all to users, unless they
> explicitly ask for it?  As it stands, it is a bit too noisy and
> in-your-face, I think.
>
> (I also don't understand why the byte-compiler does not complain about
> these variables.)

The byte compiler does not complain because when it compiles these
definitions happen to be present in the compilation environment (read
the file defining these variables was by chance already loaded).  Each
file should be consistent and compilable regardless the load history of
the Emacs used to compile (read specify the correct requires).

Given async compilation start from a fresh Emacs it's more sensitive
into spotting these errors or warnings.

Reporting these messages to the user as warnings was the result of
#44168.  Before #44168 these messages where only reported into the
*Async-native-compile-log*.

This was requested by a number of people because more than one package
missed requiring the feature containing some macro definition.  This
indeed resulted in miscompilations with the diagnostic message being
"hidden" in *Async-native-compile-log*.

Compilation units should *not* rely on the compiler environment for
their definitions.

So yeah these are real warnings or errors and package developers need to
get them somehow.  They could manifest also on non nativecomp builds if
the compilation order or something else chance.  So this is not only a
nice clean-up but also a real fix IMO.

I'm not sure what's the best action we can take to reduce the verbosity
but keep developers informed at the same time.

  Andrea