bug#66326: 29.1.50; There should be a way to promote warnings to errors

[sbaugh@catern.com]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Cc: sbaugh@catern.com,  66326@debbugs.gnu.org
>> Date: Wed, 04 Oct 2023 08:20:49 -0400
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> > And in this case, duplication is a lesser evil than reordering of
>> > logic, since the chances of unintended consequences would be lower in
>> > the former case.
>> 
>> OK, how about this version then?
>
> This is much better, thanks.  But it still fails to execute this part
> right away:
>
>   (if (not (or after-init-time noninteractive (daemonp)))
>       ;; Ensure warnings that happen early in the startup sequence
>       ;; are visible when startup completes (bug#20792).
>       (delay-warning type message level buffer-name)
>
> We must preserve this functionality, unaffected by these changes.  The
> patch you propose doesn't seem to guarantee that, at least not
> clearly enough for my palate.

Ah, actually that's deliberate.  This existing expression is meant to
delay warnings until they can be properly displayed; for warnings, that
user can't tell that the warning was delayed - whether the warning
happens during startup or at the end is indistinguishable for the user.

But if a warning is turned into an error, it would be incorrect to
signal that error later after startup is finished; it would e.g. mean
that --debug-init would just show the error being signaled at the end of
startup, instead of in the actual code that warned.

(And that's one of the motivations of this change: to make it easier to
debug a warning that happens during startup, by turning it into an error
that can be debug-init'd)