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

[Stefan Kangas <stefan@marxist.se>]

Andrea Corallo <akrl@sdf.org> writes:

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

(Sorry I didn't reply properly the last time around.)

The above reasoning is correct and valid for any ELisp package, I think.

But most of the warnings I see are actually from my init files.  There,
I specifically do not want to `require' everything I need as that would
slow down startup.  It also places undue burden on mere users that want
to customize this or that option from their init file.

And users can and do customize pretty much anything.  This is Emacs
after all.  So we can't really auto load stuff either...

Perhaps we need some special casing to detect what is an init file and
what is a package?  I have no idea how to do that reliably though, so it
might be a pipe dream.

Or maybe this will all be fixed, for some definition of fixed, when we
flip the default?

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

Yes, I agree with the plan to leave the default for now and think about
changing it closer to release.

It is your decision to close this bug or not.  As far as I'm concerned,
I think the necessary clarifications have been made and it is clear that
you are on top of things.  The other option is to mark it as blocking
Emacs 28.1 (Bug#39202) as a reminder.

Thanks again for your hard work on this branch!  I've been using it
daily since August and it is running just fine here.