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

Previous Next

Full log

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>
Cc: 44746 <at> debbugs.gnu.org, Stefan Kangas <stefan <at> marxist.se>
Subject: Re: bug#44746: 28.0.50; [feature/native-comp] Noisy "*Warnings*"
 buffer shown on start
Date: Thu, 25 Feb 2021 22:58:54 +0000

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

> Stefan Kangas <stefan <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.