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: Thu, 19 Oct 2023 15:13:49 +0300 Message-ID: <83r0lqu7wi.fsf@gnu.org> References: <83y1gj5ya9.fsf@gnu.org> <87wmw3zfd3.fsf@catern.com> <83wmw353ny.fsf@gnu.org> <83mswlslxu.fsf@gnu.org> <87o7h0yh7k.fsf@catern.com> <83a5skqvzz.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11623"; mail-complaints-to="usenet@ciao.gmane.io" Cc: sbaugh@catern.com, 66326@debbugs.gnu.org To: Spencer Baugh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 19 14:14:56 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 1qtRvU-0002nO-1N for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 19 Oct 2023 14:14:56 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qtRvG-0000HI-Im; Thu, 19 Oct 2023 08:14:42 -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 1qtRvA-0008WM-Fu for bug-gnu-emacs@gnu.org; Thu, 19 Oct 2023 08:14:37 -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 1qtRvA-00089V-6z for bug-gnu-emacs@gnu.org; Thu, 19 Oct 2023 08:14:36 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qtRva-0007rR-Ab for bug-gnu-emacs@gnu.org; Thu, 19 Oct 2023 08:15:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 19 Oct 2023 12:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66326 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 66326-submit@debbugs.gnu.org id=B66326.169771767630163 (code B ref 66326); Thu, 19 Oct 2023 12:15:02 +0000 Original-Received: (at 66326) by debbugs.gnu.org; 19 Oct 2023 12:14:36 +0000 Original-Received: from localhost ([127.0.0.1]:36017 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtRvA-0007qQ-4L for submit@debbugs.gnu.org; Thu, 19 Oct 2023 08:14:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46146) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtRv8-0007qE-L6 for 66326@debbugs.gnu.org; Thu, 19 Oct 2023 08:14:35 -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 1qtRub-00081T-QE; Thu, 19 Oct 2023 08:14:01 -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=lOEqYLMlms4BRgGPhmfiWrUswkfwH2w1am3cALzUfIk=; b=mDdiqHOe90gt ZDB+PFq82auXusFYbH0eim4nzE98e7l8OjTC9a9yIVcr0GSiZhP32dML75Q7hTqSOhC/cuhPL3qpo 24eUYz708SucOXqi3HzKpHCLZVEYGpQUbHNz3UoZv1ETp1Yv6NHWIqPzqDKeEv2p5Rs7RKW3/JPwh Jj+2zZan+GGbC142Lu3Fhgn33zhZjIz9ml8sSpxzyP08ob1KCWp3ARipDM6tykKMqKnVH6WcosLs8 tcWbcSoZX+Nhmi1Ys5gRgnaUdwUAdmEJXafin/TCyLORHUojOXZEfiU4o+5zY+LI61CSSkBsNgagE AoNxgxO8f9HKu3bcOMGpDg==; In-Reply-To: (message from Spencer Baugh on Mon, 16 Oct 2023 15:26:51 -0400) 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:272728 Archived-At: > From: Spencer Baugh > Cc: sbaugh@catern.com, 66326@debbugs.gnu.org > Date: Mon, 16 Oct 2023 15:26:51 -0400 > > > If it's deliberate, it will have to come with an additional option to > > enable it. I don't want users to have their startup aborted just > > because they want some warning later on converted to an error. > > Startup is a delicate process where signaling errors is not always a > > good idea, and we delay warnings there for a good reason. Changing > > this unconditionally is not acceptable. > > What is the good reason that we delay warnings? Because Emacs is not yet able to display stuff reliably, for example. Or the display environment was not yet set up completely. > But OK, attached is a new patch which adds an option to immediately > raise the warnings converted into errors during startup, instead of > delaying them. So the default is to delay the error until after > startup. Does this work? Did you test that? If you did, what happens with delayed warnings when the new option is nil? > > There's no difficulty in debugging a warning whatsoever, IME. It is a > > serious exaggeration to claim that there's a significant problem here > > that needs a solution. > > I'm curious: if you have some piece of code which warns during startup, > how would you find out why that code is running? By searching for the warning text and analyzing the code which invokes the warning, of course. And that's only if the warning message itself doesn't explain itself (which a good warning should). > e.g., how would you figure out what function is calling some other > code which internally warns? This seems pretty difficult to me. I normally find this unnecessary. In very rare and extreme situations, I run Emacs under GDB. Like I said: this is a niche feature, which seems to have grown out of some very specific experience you had at some point. It is not at all common enough to consider it important. So the last thing we should allow is for it to introduce regressions, and IME messing with startup code runs a very high risk of introducing regressions. > --- a/lisp/emacs-lisp/warnings.el > +++ b/lisp/emacs-lisp/warnings.el > @@ -114,11 +114,37 @@ warning-suppress-types > The element must match an initial segment of the list TYPE. > Thus, (foo bar) as an element matches (foo bar) > or (foo bar ANYTHING...) as TYPE. > +An empty list as an element matches any TYPE. Why was this change necessary? An empty list is the same as nil, and treating nil as matching everything is unusual and unintuitive, IMO. If this option is really needed and important, the value of t is much more natural. > +(defcustom warning-to-error-types nil > + "List of warning types to signal as an error instead. ^^^^^^^ "instead of a warning". Or maybe even List of types of warnings that will be converted to errors. > +If any element of this list matches the TYPE argument to `display-warning', > +`display-warning' signals an error instead of logging a warning. "Logging" is not a good terminology here, as warning are "displayed", not "logged". > +(defcustom warning-signal-errors-during-startup nil > + "If non-nil, warnings converted into errors are signaled during startup. "Whether to signal errors converted from warnings during startup." > +Normally, warnings generated during startup are delayed until > +after startup. This includes warnings converted into errors by > +`warning-to-error-types': they will be signaled after startup > +completes, outside the context of the code which caused the > +warning. If you'd prefer that these errors be signaled > +immediately so that the context is present during debugging, set > +this variable to nil." I think this should explain what does "after startup" mean, and also mention the special case of daemon. > (defun display-warning (type message &optional level buffer-name) > "Display a warning message, MESSAGE. > @@ -263,6 +299,14 @@ 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." > + (when (and (>= (warning-numeric-level (or level :warning)) > + (warning-numeric-level warning-minimum-log-level)) > + (not (warning-suppress-p type warning-suppress-log-types)) > + (warning-suppress-p type warning-to-error-types) > + (or warning-signal-errors-during-startup > + after-init-time noninteractive (daemonp)) > + ) I'd suggest to move the last condition to be the first one, or thereabouts, as the default values will then make this code a tad faster