bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#66326: 29.1.50; There should be a way to promote warnings to errors
Date: Tue, 03 Oct 2023 21:57:50 +0300

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Tue, 03 Oct 2023 14:39:02 -0400
> 
> +(defcustom warning-to-error-types nil
> +  "List of warning types to signal as an error instead.
> +If any element of this list matches the TYPE argument to `display-warning',
> +an error is signaled instead of logging a warning.
   ^^^^^^^^^^^^^^^^^^^^
Passive voice alert!

>  (defun display-warning (type message &optional level buffer-name)
>    "Display a warning message, MESSAGE.
> @@ -263,105 +278,109 @@ display-warning
>  disable automatic display of the warning or disable the warning
>  entirely by setting `warning-suppress-types' or
>  `warning-suppress-log-types' on their behalf."
> -  (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)
> -    (unless level
> -      (setq level :warning))
> -    (unless buffer-name
> -      (setq buffer-name "*Warnings*"))
> +  (unless level
> +    (setq level :warning))
> +  (unless buffer-name
> +    (setq buffer-name "*Warnings*"))
> +  (cond
> +   ((< (warning-numeric-level level)
> +       (warning-numeric-level warning-minimum-log-level)))
> +   ((warning-suppress-p type warning-suppress-log-types))
> +   ((warning-suppress-p type warning-to-error-types)
> +    (warning-to-error type message level))
> +   ((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))
> +   (t

AFAICT, this reorders parts of the evaluation, and thus changes the
semantics/behavior.  Please try to keep the order of the evaluation
the same as it was, to avoid unintended consequences.  (It will also
make the patch review easier.)

Thanks.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]