From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#66326: 29.1.50; There should be a way to promote warnings to errors Date: Wed, 04 Oct 2023 08:59:13 +0300 Message-ID: <83wmw353ny.fsf@gnu.org> References: <83y1gj5ya9.fsf@gnu.org> <87wmw3zfd3.fsf@catern.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38783"; mail-complaints-to="usenet@ciao.gmane.io" Cc: sbaugh@janestreet.com, 66326@debbugs.gnu.org To: sbaugh@catern.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Oct 04 08:00:09 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qnuvW-0009k9-Ud for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 04 Oct 2023 08:00:07 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qnuvD-0008KP-J1; Wed, 04 Oct 2023 01:59:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qnuvA-00088E-R9 for bug-gnu-emacs@gnu.org; Wed, 04 Oct 2023 01:59:45 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qnuvA-0001oo-In for bug-gnu-emacs@gnu.org; Wed, 04 Oct 2023 01:59:44 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qnuvR-0002MF-V2 for bug-gnu-emacs@gnu.org; Wed, 04 Oct 2023 02:00:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 04 Oct 2023 06:00:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66326 X-GNU-PR-Package: emacs Original-Received: via spool by 66326-submit@debbugs.gnu.org id=B66326.16963991778982 (code B ref 66326); Wed, 04 Oct 2023 06:00:01 +0000 Original-Received: (at 66326) by debbugs.gnu.org; 4 Oct 2023 05:59:37 +0000 Original-Received: from localhost ([127.0.0.1]:41260 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qnuv3-0002Kn-74 for submit@debbugs.gnu.org; Wed, 04 Oct 2023 01:59:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58192) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qnuv0-0002Ka-Q2 for 66326@debbugs.gnu.org; Wed, 04 Oct 2023 01:59:36 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qnuuc-0001kx-Th; Wed, 04 Oct 2023 01:59:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=2tWzHFTk66VD76R+9cbjzPJQEHEfbRj/6CoQ8Q3046c=; b=RMVFmawBk0MA vTawNpaYTkFR1s9JWR8aFbRofyvgZ2utord1rELLbo/66J1uV9eqjOBgbuHY2yJ8+M6WcOYEAI3UT g82Qvw2gRlLNKkvej5rJt2BPBcL80EFZDosv41a3dvoxh/1jjhQ8yVaMO814KiMcNJyz7kJ/P8cHx vEoPuzWW+T7C0p3o04hMfeDVDfZeJwGEBNbAcJkptrlAXBhTgZ6KLrbWTAZ+mYraC/YAY+SOeWFOp bh454Xmhvrkm46g/zjFmGpHVg09GYs9ZPFOS8wxULm4YjFOJY+rfwg0O49Mcax+NJwRQMlOAMk4n2 S2u8sxe1PgKMisYOMGVSFw==; In-Reply-To: <87wmw3zfd3.fsf@catern.com> (sbaugh@catern.com) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:271759 Archived-At: > From: sbaugh@catern.com > Date: Tue, 03 Oct 2023 19:16:09 +0000 (UTC) > Cc: Spencer Baugh , 66326@debbugs.gnu.org > > Eli Zaretskii writes: > > >> From: Spencer Baugh > >> 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.) > > Unfortuantely it's not possible to avoid either reordering the > evaluation or duplicating some parts of it. Because, of course we want > a warning to not become an error if it's listed in > warning-suppress-log-types, and we do want it to become an error even if > it occurs early in the startup sequence. So the > warning-suppress-log-types check has to happen before the to-error > check, and the to-error check has to happen before the early-startup > check. Even if the above is true, I see no justification to calling delay-warning with overridden values of level and buffer, and after the other 'cond' cases, where it originally was called right away. 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. > Reordering them doesn't actually change behavior, because the > early-startup check just delays the warning, so it should be fine. Famous last words. When will we learn that Emacs is so much complex that we should humbly realize we never have the full picture to make such cavalier assumptions? > I can separate out the reordering change into a separate patch if you > like, then you can see that it should not change behavior. No, that won't help me to be sure we are not introducing some incompatible changes in this long-standing behavior. Please realize: this is a very minor feature, useful in a small number of situations, so the risk of it causing us trouble in the much more important cases of issuing and delaying warnings is unacceptable. So unless I'm reasonably sure this risk is very low, I will simply not agree to installing this feature. TIA