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

[Andrea Corallo]

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

> 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

To complete this answer, ATM is possible to gate all warnings reported
by async native compilations leveraging the
`comp-async-report-warnings-errors' customize.

Is this sufficient to close this bug or do we like to discuss this
default?

My opinion (got it from the discussion on emacs-devel) is that at least
for now would be good to keep `comp-async-report-warnings-errors' to t
for the reason I've explained in the mail I'm quoting.  Perhaps we could
think about revisiting this default but probably in the future.

Thanks

  Andrea