From sand@blarg.net Thu Feb 26 20:40:31 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 27 Feb 2009 04:40:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.1 required=4.0 tests=FOURLA autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n1R4eRF5012884 for ; Thu, 26 Feb 2009 20:40:29 -0800 Received: from mail.gnu.org ([199.232.76.166]:56494 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LcuUC-00085c-NU for emacs-pretest-bug@gnu.org; Thu, 26 Feb 2009 23:38:08 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LcuWN-0001bZ-3E for emacs-pretest-bug@gnu.org; Thu, 26 Feb 2009 23:40:26 -0500 Received: from v-static-143-234.avvanta.com ([206.124.143.234]:34674 helo=priss.frightenedpiglet.com) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1LcuWM-0001bP-DS for emacs-pretest-bug@gnu.org; Thu, 26 Feb 2009 23:40:22 -0500 Received: (qmail 3647 invoked by uid 1000); 27 Feb 2009 04:14:20 -0000 Date: 27 Feb 2009 04:14:20 -0000 Message-ID: <20090227041420.3646.qmail@priss.frightenedpiglet.com> From: sand@blarg.net To: emacs-pretest-bug@gnu.org CC: rfrancoise@debian.org Subject: 23.0.90; Flymake too aggressive when responding to unusual error combination X-URL: http://home.blarg.net/~sand X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-Greylist: delayed 1601 seconds by postgrey-1.27 at monty-python; Thu, 26 Feb 2009 23:40:21 EST Background ---------- The Flymake library shipped with CVS HEAD (and probably earlier) has the following code in `flymake-post-syntax-check': (defun flymake-post-syntax-check (exit-status command) ;; [. . . elided . . .] (if (and (equal 0 err-count) (equal 0 warn-count)) (if (equal 0 exit-status) (flymake-report-status "" "") ; PASSED (if (not flymake-check-was-interrupted) (flymake-report-fatal-status "CFGERR" (format "Configuration error has occured while running %s" command)) (flymake-report-status nil ""))) ; "STOPPED" (flymake-report-status (format "%d/%d" err-count warn-count) ""))) Depending on... ...whether the flymake check generated errors or warnings, ...whether the flymake check had a non-zero exit status, and ...whether we interrupted the flymake check, we can generate any of four different statuses. One of the statuses, "CFGERR" is fatal, and turns off flymake for that buffer. The others are non-fatal. Problem ------- Flymake only tracks errors that refer to the specific file being checked. For example, given the following output for "foo.c", which includes file "bar.h" foo.c:20: warning: Type mismatch bar.h:30: error: Invalid syntax Flymake would "see" one warning and no errors. The "bar.h" error is dropped. Now consider the degenerate case where "bar.h" is the only source of errors, *and the check returns a non-zero exit status*: bar.h:30: error: Invalid syntax The error and warning counts are zero, the exit status is non-zero, the check was not interrupted, so we end up reporting a fatal CFGERR. Think aobut the user experience here, with the two examples shown above. First, Flymake checks, and reports an warning in the current file "foo.c". The user fixes the warning. Then Flymake reports a fatal error (popping up a dialog box under X) and turns itself off! Solution -------- That particular code branch is supposed to catch cases where the build system itself dies with an error, which is important to detect. But shutting down Flymake is too excessive a response, because of errors in included files. The following replacement code changes the behavior to report zero errors and zero warnings with the file itself, but it adds a ":CFGERR" flag to indicate that there was some other problem with the check. Flymake remains enabled for the buffer. (defun flymake-post-syntax-check (exit-status command) ;; [. . . elided . . .] (if (and (equal 0 err-count) (equal 0 warn-count)) (if (equal 0 exit-status) (flymake-report-status "" "") ; PASSED (if (not flymake-check-was-interrupted) (flymake-report-status "0/0" ":CFGERR") (flymake-report-status nil ""))) ; "STOPPED" (flymake-report-status (format "%d/%d" err-count warn-count) ""))) Derek In GNU Emacs 23.0.90.1 (i486-pc-linux-gnu, GTK+ Version 2.12.11) of 2009-02-07 on elegiac, modified by Debian (emacs-snapshot package, version 1:20090207-1) Windowing system distributor `The X.Org Foundation', version 11.0.10402000 configured using `configure '--build' 'i486-linux-gnu' '--host' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/23.0.90/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.0.90/site-lisp:/usr/share/emacs/site-lisp' '--with-x=yes' '--with-x-toolkit=gtk' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2' 'LDFLAGS=-g -Wl,--as-needed' 'CPPFLAGS='' From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 13 23:48:39 2016 Received: (at 2491) by debbugs.gnu.org; 14 Jan 2016 04:48:39 +0000 Received: from localhost ([127.0.0.1]:48707 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aJZpv-0001ji-FS for submit@debbugs.gnu.org; Wed, 13 Jan 2016 23:48:39 -0500 Received: from mail-qg0-f46.google.com ([209.85.192.46]:34292) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aJZpt-0001jV-8X for 2491@debbugs.gnu.org; Wed, 13 Jan 2016 23:48:37 -0500 Received: by mail-qg0-f46.google.com with SMTP id 6so393533868qgy.1 for <2491@debbugs.gnu.org>; Wed, 13 Jan 2016 20:48:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=AyM94RaP57HP7ad83NH0LE3WQ62VLKVI/b40HV80tB0=; b=ssVWlWsj+RBSxpu710gc4E2IWXa5KTi44apPgapQ7peV3JXovNGZmtZf5ZO/QhJ/Jw Ngku1M5bftgv0EOxQ6pqUxLjo2pPPfnW+iXwmqwwi+Di16V5ouTvSVCgj1tSDkW+z7KL DnjJqf2mQkXogVxNBw+S4l3XIqOsLYcI1ccQpt3QYGCAPWTVGCW4sGsPOGgQBfDS6p9l F3bH2tCF/LVqiIxTIwKk4Q2PnTDETtH4JT3NQKC00HX9VeVQrk+Dj1I3lShTsdVbPFoK rTd0d16+kdHpIRAAsvvQr/0QC7+S4riad8g35y4v4E3y715zQgmsDDR5XMNdGHE9BDuH cI3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=AyM94RaP57HP7ad83NH0LE3WQ62VLKVI/b40HV80tB0=; b=DBxTwJDeOHACi9LwFF7T8ILlGRPMDRCjebE3pGbCBK4kx6DDZyV8sqZNzjsDCllogT LLM7n5EXLeudPGFg3PuhrnMgLl1WsafVtsciL+4KhyjdKyrnmwNgTx9k19WnBGlpoQ9G wLFjZ677OUBzAh3pkg1anmpaatL6yyAHkCKVa7Sr6TsPAC1aXSNVnifOv7kwYkj5R/et urIl/7bbjGhuO1p2TJd6YM+sw49kwzxQhg1bqUqLDH6PXFEAhS1z4QcCM5E9nyFXD6xI hxDwoIggqo3lhHQkW1EpdgCDX+rlwG+1Jb0VSqnkm58rwkLsjzsFsJZIHZm4OqIOTj6e yUkg== X-Gm-Message-State: ALoCoQkQOi/uFSIKwljowAOOLLjIyAepGKOuiD/J2RQ5kZERG+1dxOPUL1yW68tI3g5ifnyZQbkF3kACq1yfptiKT6oa4tvMHQ== X-Received: by 10.140.174.2 with SMTP id u2mr2726414qhu.62.1452746911548; Wed, 13 Jan 2016 20:48:31 -0800 (PST) Received: from Andrews-MacBook-Pro.local.ahyatt-laptop (cpe-74-73-128-199.nyc.res.rr.com. [74.73.128.199]) by smtp.gmail.com with ESMTPSA id q30sm1881540qkq.11.2016.01.13.20.48.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jan 2016 20:48:29 -0800 (PST) From: Andrew Hyatt To: sand@blarg.net Subject: Re: bug#2491: 23.0.90; Flymake too aggressive when responding to unusual error combination References: <20090227041420.3646.qmail@priss.frightenedpiglet.com> Date: Wed, 13 Jan 2016 23:48:26 -0500 In-Reply-To: <20090227041420.3646.qmail@priss.frightenedpiglet.com> (sand@blarg.net's message of "27 Feb 2009 04:14:20 -0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 2491 Cc: 2491@debbugs.gnu.org, rfrancoise@debian.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Thanks for the bug report, and sorry it's sat so long without any movement. Looking over this, I don't particularly understand the issue (why would the check return a non-zero exit status if it was working properly?) It might help if you provided a simple example. I've looked at the code in Emacs 25, though, and it still has the logic you report. sand@blarg.net writes: > Background > ---------- > > The Flymake library shipped with CVS HEAD (and probably earlier) has > the following code in `flymake-post-syntax-check': > > (defun flymake-post-syntax-check (exit-status command) > ;; [. . . elided . . .] > > (if (and (equal 0 err-count) (equal 0 warn-count)) > (if (equal 0 exit-status) > (flymake-report-status "" "") ; PASSED > (if (not flymake-check-was-interrupted) > (flymake-report-fatal-status "CFGERR" > (format "Configuration error has occured while running %s" command)) > (flymake-report-status nil ""))) ; "STOPPED" > (flymake-report-status (format "%d/%d" err-count warn-count) ""))) > > Depending on... > > ...whether the flymake check generated errors or warnings, > ...whether the flymake check had a non-zero exit status, and > ...whether we interrupted the flymake check, > > we can generate any of four different statuses. One of the statuses, > "CFGERR" is fatal, and turns off flymake for that buffer. The others > are non-fatal. > > Problem > ------- > > Flymake only tracks errors that refer to the specific file being > checked. For example, given the following output for "foo.c", > which includes file "bar.h" > > foo.c:20: warning: Type mismatch > bar.h:30: error: Invalid syntax > > Flymake would "see" one warning and no errors. The "bar.h" error is > dropped. Now consider the degenerate case where "bar.h" is the only > source of errors, *and the check returns a non-zero exit status*: > > bar.h:30: error: Invalid syntax > > The error and warning counts are zero, the exit status is non-zero, > the check was not interrupted, so we end up reporting a fatal CFGERR. > > Think aobut the user experience here, with the two examples shown > above. First, Flymake checks, and reports an warning in the current > file "foo.c". The user fixes the warning. Then Flymake reports a > fatal error (popping up a dialog box under X) and turns itself off! > > Solution > -------- > > That particular code branch is supposed to catch cases where the build > system itself dies with an error, which is important to detect. But > shutting down Flymake is too excessive a response, because of errors > in included files. > > The following replacement code changes the behavior to report zero > errors and zero warnings with the file itself, but it adds a ":CFGERR" > flag to indicate that there was some other problem with the check. > Flymake remains enabled for the buffer. > > (defun flymake-post-syntax-check (exit-status command) > ;; [. . . elided . . .] > > (if (and (equal 0 err-count) (equal 0 warn-count)) > (if (equal 0 exit-status) > (flymake-report-status "" "") ; PASSED > (if (not flymake-check-was-interrupted) > (flymake-report-status "0/0" ":CFGERR") > (flymake-report-status nil ""))) ; "STOPPED" > (flymake-report-status (format "%d/%d" err-count warn-count) ""))) > > > Derek > > > > > In GNU Emacs 23.0.90.1 (i486-pc-linux-gnu, GTK+ Version 2.12.11) > of 2009-02-07 on elegiac, modified by Debian > (emacs-snapshot package, version 1:20090207-1) > Windowing system distributor `The X.Org Foundation', version 11.0.10402000 > configured using `configure '--build' 'i486-linux-gnu' '--host' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/23.0.90/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.0.90/site-lisp:/usr/share/emacs/site-lisp' '--with-x=yes' '--with-x-toolkit=gtk' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2' 'LDFLAGS=-g -Wl,--as-needed' 'CPPFLAGS='' From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 14 21:49:02 2016 Received: (at 2491) by debbugs.gnu.org; 15 Jan 2016 02:49:02 +0000 Received: from localhost ([127.0.0.1]:49526 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aJuRh-0006Lz-OE for submit@debbugs.gnu.org; Thu, 14 Jan 2016 21:49:02 -0500 Received: from smtp61.avvanta.com ([206.124.128.61]:55560 helo=mail.avvanta.com) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aJuRf-0006Ll-UV for 2491@debbugs.gnu.org; Thu, 14 Jan 2016 21:49:00 -0500 Received: from mail.avvanta.com (localhost.rowlf.p [127.0.0.1]) by mail.avvanta.com (Postfix) with ESMTP id 0E24A93C81; Thu, 14 Jan 2016 18:47:06 -0800 (PST) Received: from priss.frightenedpiglet.com (c-98-225-51-194.hsd1.wa.comcast.net [98.225.51.194]) by mail.avvanta.com (Postfix) with ESMTP id EC71B93C40; Thu, 14 Jan 2016 18:47:05 -0800 (PST) Received: from localhost ([127.0.0.1] helo=priss.frightenedpiglet.com) by priss.frightenedpiglet.com with esmtp (Exim 4.86) (envelope-from ) id 1aJuRe-0002us-1B; Thu, 14 Jan 2016 18:48:58 -0800 References: <20090227041420.3646.qmail@priss.frightenedpiglet.com> User-agent: mu4e 0.9.9.5; emacs 25.0.50.1 From: Derek Upham To: Andrew Hyatt Subject: Re: bug#2491: 23.0.90; Flymake too aggressive when responding to unusual error combination In-reply-to: Date: Thu, 14 Jan 2016 18:48:57 -0800 Message-ID: <87io2vd0bq.fsf@priss.frightenedpiglet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BlargAV-Status: No viruses detected, BlargAV v1.1 on localhost.scooter.p.blarg.net X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 2491 Cc: 2491@debbugs.gnu.org, rfrancoise@debian.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) The situation is a flymake check for “foo.c”, where “foo.c” is perfectly fine but it #includes “bar.h” which has a syntax error. Flymake triggers a compilation. The compilation fails due to the syntax error, returning a non-zero exit status, along with the text bar.h:30: error: Invalid syntax Flymake quietly drops any error messages that refer to anything other than “foo.c”. As far as it is concerned, the above error output is empty. That means... - The error and warning counts are zero - The exit status is non-zero - The check was not interrupted The nested ‘if’ clauses in ‘flymake-post-syntax-check’ route control through: (flymake-report-fatal-status "CFGERR" (format "Configuration error has occured while running %s" command)) This code reports a fatal error and permanently turns off Flymake in the buffer. After you fix the syntax error in “bar.h”, you have to restart Flymake in “foo.c” (and any other files that depended on it). The bug is that we need to explicitly restart Flymake. The proposed solution in the bug report is to treat this case as a non-fatal situation, with a special mode line tag to indicate “there’s a deeper problem”. (It would be great if we could point the user to an error in “bar.h” line 30, but I don’t think there’s a good way to do it in the UI.) Upon reflection, I think it’s better for Flymake to keep counts of errors and warnings in “other” files (not ignore them) and use that to improve the post-syntax-check tests with another “if” clause. (I’m pretty sure this was with Erlang code, which is why no one else has encountered the bug. As I recall, GCC provides enough breadcrumbs that the #include line in the .c file will be tagged as a problem. The Erlang compiler doesn’t show that information, or didn’t back then.) Derek ahyatt@gmail.com writes: > Thanks for the bug report, and sorry it's sat so long without any > movement. Looking over this, I don't particularly understand the issue > (why would the check return a non-zero exit status if it was working > properly?) It might help if you provided a simple example. > > I've looked at the code in Emacs 25, though, and it still has the logic > you report. > > sand@blarg.net writes: > >> Background >> ---------- >> >> The Flymake library shipped with CVS HEAD (and probably earlier) has >> the following code in `flymake-post-syntax-check': >> >> (defun flymake-post-syntax-check (exit-status command) >> ;; [. . . elided . . .] >> >> (if (and (equal 0 err-count) (equal 0 warn-count)) >> (if (equal 0 exit-status) >> (flymake-report-status "" "") ; PASSED >> (if (not flymake-check-was-interrupted) >> (flymake-report-fatal-status "CFGERR" >> (format "Configuration error has occured while running %s" command)) >> (flymake-report-status nil ""))) ; "STOPPED" >> (flymake-report-status (format "%d/%d" err-count warn-count) ""))) >> >> Depending on... >> >> ...whether the flymake check generated errors or warnings, >> ...whether the flymake check had a non-zero exit status, and >> ...whether we interrupted the flymake check, >> >> we can generate any of four different statuses. One of the statuses, >> "CFGERR" is fatal, and turns off flymake for that buffer. The others >> are non-fatal. >> >> Problem >> ------- >> >> Flymake only tracks errors that refer to the specific file being >> checked. For example, given the following output for "foo.c", >> which includes file "bar.h" >> >> foo.c:20: warning: Type mismatch >> bar.h:30: error: Invalid syntax >> >> Flymake would "see" one warning and no errors. The "bar.h" error is >> dropped. Now consider the degenerate case where "bar.h" is the only >> source of errors, *and the check returns a non-zero exit status*: >> >> bar.h:30: error: Invalid syntax >> >> The error and warning counts are zero, the exit status is non-zero, >> the check was not interrupted, so we end up reporting a fatal CFGERR. >> >> Think aobut the user experience here, with the two examples shown >> above. First, Flymake checks, and reports an warning in the current >> file "foo.c". The user fixes the warning. Then Flymake reports a >> fatal error (popping up a dialog box under X) and turns itself off! >> >> Solution >> -------- >> >> That particular code branch is supposed to catch cases where the build >> system itself dies with an error, which is important to detect. But >> shutting down Flymake is too excessive a response, because of errors >> in included files. >> >> The following replacement code changes the behavior to report zero >> errors and zero warnings with the file itself, but it adds a ":CFGERR" >> flag to indicate that there was some other problem with the check. >> Flymake remains enabled for the buffer. >> >> (defun flymake-post-syntax-check (exit-status command) >> ;; [. . . elided . . .] >> >> (if (and (equal 0 err-count) (equal 0 warn-count)) >> (if (equal 0 exit-status) >> (flymake-report-status "" "") ; PASSED >> (if (not flymake-check-was-interrupted) >> (flymake-report-status "0/0" ":CFGERR") >> (flymake-report-status nil ""))) ; "STOPPED" >> (flymake-report-status (format "%d/%d" err-count warn-count) ""))) >> >> >> Derek >> >> >> >> >> In GNU Emacs 23.0.90.1 (i486-pc-linux-gnu, GTK+ Version 2.12.11) >> of 2009-02-07 on elegiac, modified by Debian >> (emacs-snapshot package, version 1:20090207-1) >> Windowing system distributor `The X.Org Foundation', version 11.0.10402000 >> configured using `configure '--build' 'i486-linux-gnu' '--host' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' > '--with-pop=yes' '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/23.0.90/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.0.90/site-lisp:/usr/share/emacs/site-lisp' > '--with-x=yes' '--with-x-toolkit=gtk' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2' 'LDFLAGS=-g -Wl,--as-needed' 'CPPFLAGS='' -- Derek Upham sand@blarg.net From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 24 16:23:40 2016 Received: (at 2491) by debbugs.gnu.org; 24 Jan 2016 21:23:40 +0000 Received: from localhost ([127.0.0.1]:35212 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNS8K-0001eQ-2b for submit@debbugs.gnu.org; Sun, 24 Jan 2016 16:23:40 -0500 Received: from mail-qg0-f53.google.com ([209.85.192.53]:34275) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNS8H-0001eB-S7 for 2491@debbugs.gnu.org; Sun, 24 Jan 2016 16:23:38 -0500 Received: by mail-qg0-f53.google.com with SMTP id 6so95634590qgy.1 for <2491@debbugs.gnu.org>; Sun, 24 Jan 2016 13:23:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=yACA1WOZrduYhqQRI7A+hBYRy91vCAL2G0NVlK55nDo=; b=brPzhMxZ5vjeo9JPSW+0sR6pWYO618yC0+CLULSn4dcDY6JIC96vqg81BDM9Sj3uml lz1Vv1ag1RxI5c9S8xNmpIy+6s6Iaea9REXZw+SxacuMeaPdoXsLa68A1mHVKxZqwhJT khtGUQf3OsCF0/VUjYRCUZFpija3xHr+yMGmBGECTO/CFnGVQWHgt76V4GQ8tSLvf3m4 Fd932qaUDEp1bhppxJT9H7QuSoH4Tl/pnTGrCNje1iwP3/vzAo/86Brp+yRHfi2ae6zc anIYrUhdROwK1oCmB8AaSmNSLEgtNpXBv5LftcoGoWA6VgkV4ky8/rWR/CJUIQhv16SD LrUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type :content-transfer-encoding; bh=yACA1WOZrduYhqQRI7A+hBYRy91vCAL2G0NVlK55nDo=; b=TkuFMyDcr1LDxn/roQoezwgIFHCzIz0421UzmxMrASEyJBlROhvqS5AxStqu+DxG0N vPQCWqJG/wF0Q6VW/07XRu0apDB774VZz7Bwd8uHBhEZJ5VYqxSuksnlbB+D0fql/e/E ALENYvrFxpRlJr0WBnV43W7cwudP8ulzcQFRrmUQbFb7pBCOWDZtShSpq6NT3HBlcb8J fCtq8zJ0qBUHksDhoDc/RUpKOPXtQPz6I5jRdu60O8xTTxJmnq04wCeheJEvpDRrOJU7 zInkmsnLwpfWvO7QFYVI35kypUC6ooFVeg0lXhiilFnIZBdngEba4GgiF14jAf/uMUO5 2vtg== X-Gm-Message-State: AG10YORFmg0miO6q0fHpVgLyjw8wNKee+/w9PegGgy8VsYW4gpfR6jO1KdEI3yyqDIYWBQ== X-Received: by 10.140.155.87 with SMTP id b84mr17599562qhb.29.1453670612487; Sun, 24 Jan 2016 13:23:32 -0800 (PST) Received: from Andrews-MacBook-Pro.local.ahyatt-laptop (cpe-74-73-128-199.nyc.res.rr.com. [74.73.128.199]) by smtp.gmail.com with ESMTPSA id a66sm7522544qkb.20.2016.01.24.13.23.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Jan 2016 13:23:30 -0800 (PST) From: Andrew Hyatt To: Derek Upham Subject: Re: bug#2491: 23.0.90; Flymake too aggressive when responding to unusual error combination References: <20090227041420.3646.qmail@priss.frightenedpiglet.com> <87io2vd0bq.fsf@priss.frightenedpiglet.com> Date: Sun, 24 Jan 2016 16:23:28 -0500 In-Reply-To: <87io2vd0bq.fsf@priss.frightenedpiglet.com> (Derek Upham's message of "Thu, 14 Jan 2016 18:48:57 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 2491 Cc: 2491@debbugs.gnu.org, rfrancoise@debian.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Got it. So, if I understand correctly, this may or may not be fixed, but in any case, it seems specific to Erlang. Hopefully you, or another Erlang user, can attempt to reproduce it so that we can move forward on this bug. Derek Upham writes: > The situation is a flymake check for =E2=80=9Cfoo.c=E2=80=9D, where =E2= =80=9Cfoo.c=E2=80=9D is perfectly fine but it #includes =E2=80=9Cbar.h=E2= =80=9D which has a syntax error. > > Flymake triggers a compilation. The compilation fails due to the syntax = error, returning a non-zero exit status, along with the text > > bar.h:30: error: Invalid syntax > > Flymake quietly drops any error messages that refer to anything other tha= n =E2=80=9Cfoo.c=E2=80=9D. As far as it is concerned, the above error outp= ut is empty. That means... > > - The error and warning counts are zero > - The exit status is non-zero > - The check was not interrupted > > The nested =E2=80=98if=E2=80=99 clauses in =E2=80=98flymake-post-syntax-c= heck=E2=80=99 route control through: > > (flymake-report-fatal-status "CFGERR" > (format "Configuration error has occured while running %s" command)) > > This code reports a fatal error and permanently turns off Flymake in the = buffer. After you fix the syntax error in =E2=80=9Cbar.h=E2=80=9D, you hav= e to restart Flymake in =E2=80=9Cfoo.c=E2=80=9D (and any other files that d= epended on it). The bug is that we need to explicitly restart Flymake. > > The proposed solution in the bug report is to treat this case as a non-fa= tal situation, with a special mode line tag to indicate =E2=80=9Cthere=E2= =80=99s a deeper problem=E2=80=9D. (It would be great if we could point th= e user to an error in =E2=80=9Cbar.h=E2=80=9D line 30, but I don=E2=80=99t = think there=E2=80=99s a good way to do it in the UI.) Upon reflection, I t= hink it=E2=80=99s better for Flymake to keep counts of errors and warnings = in =E2=80=9Cother=E2=80=9D files (not ignore them) and use that to improve = the post-syntax-check tests with another =E2=80=9Cif=E2=80=9D clause. > > (I=E2=80=99m pretty sure this was with Erlang code, which is why no one e= lse has encountered the bug. As I recall, GCC provides enough breadcrumbs = that the #include line in the .c file will be tagged as a problem. The Erl= ang compiler doesn=E2=80=99t show that information, or didn=E2=80=99t back = then.) > > Derek > > ahyatt@gmail.com writes: > >> Thanks for the bug report, and sorry it's sat so long without any >> movement. Looking over this, I don't particularly understand the issue >> (why would the check return a non-zero exit status if it was working >> properly?) It might help if you provided a simple example. >> >> I've looked at the code in Emacs 25, though, and it still has the logic >> you report. >> >> sand@blarg.net writes: >> >>> Background >>> ---------- >>> >>> The Flymake library shipped with CVS HEAD (and probably earlier) has >>> the following code in `flymake-post-syntax-check': >>> >>> (defun flymake-post-syntax-check (exit-status command) >>> ;; [. . . elided . . .] >>> >>> (if (and (equal 0 err-count) (equal 0 warn-count)) >>> (if (equal 0 exit-status) >>> (flymake-report-status "" "") ; PASSED >>> (if (not flymake-check-was-interrupted) >>> (flymake-report-fatal-status "CFGERR" >>> (format "Configuration error has occured while running %s" command)) >>> (flymake-report-status nil ""))) ; "STOPPED" >>> (flymake-report-status (format "%d/%d" err-count warn-count) ""))) >>> >>> Depending on... >>> >>> ...whether the flymake check generated errors or warnings, >>> ...whether the flymake check had a non-zero exit status, and >>> ...whether we interrupted the flymake check, >>> >>> we can generate any of four different statuses. One of the statuses, >>> "CFGERR" is fatal, and turns off flymake for that buffer. The others >>> are non-fatal. >>> >>> Problem >>> ------- >>> >>> Flymake only tracks errors that refer to the specific file being >>> checked. For example, given the following output for "foo.c", >>> which includes file "bar.h" >>> >>> foo.c:20: warning: Type mismatch >>> bar.h:30: error: Invalid syntax >>> >>> Flymake would "see" one warning and no errors. The "bar.h" error is >>> dropped. Now consider the degenerate case where "bar.h" is the only >>> source of errors, *and the check returns a non-zero exit status*: >>> >>> bar.h:30: error: Invalid syntax >>> >>> The error and warning counts are zero, the exit status is non-zero, >>> the check was not interrupted, so we end up reporting a fatal CFGERR. >>> >>> Think aobut the user experience here, with the two examples shown >>> above. First, Flymake checks, and reports an warning in the current >>> file "foo.c". The user fixes the warning. Then Flymake reports a >>> fatal error (popping up a dialog box under X) and turns itself off! >>> >>> Solution >>> -------- >>> >>> That particular code branch is supposed to catch cases where the build >>> system itself dies with an error, which is important to detect. But >>> shutting down Flymake is too excessive a response, because of errors >>> in included files. >>> >>> The following replacement code changes the behavior to report zero >>> errors and zero warnings with the file itself, but it adds a ":CFGERR" >>> flag to indicate that there was some other problem with the check. >>> Flymake remains enabled for the buffer. >>> >>> (defun flymake-post-syntax-check (exit-status command) >>> ;; [. . . elided . . .] >>> >>> (if (and (equal 0 err-count) (equal 0 warn-count)) >>> (if (equal 0 exit-status) >>> (flymake-report-status "" "") ; PASSED >>> (if (not flymake-check-was-interrupted) >>> (flymake-report-status "0/0" ":CFGERR") >>> (flymake-report-status nil ""))) ; "STOPPED" >>> (flymake-report-status (format "%d/%d" err-count warn-count) ""))) >>> >>> >>> Derek >>> >>> >>> >>> >>> In GNU Emacs 23.0.90.1 (i486-pc-linux-gnu, GTK+ Version 2.12.11) >>> of 2009-02-07 on elegiac, modified by Debian >>> (emacs-snapshot package, version 1:20090207-1) >>> Windowing system distributor `The X.Org Foundation', version 11.0.10402= 000 >>> configured using `configure '--build' 'i486-linux-gnu' '--host' >>> 'i486-linux-gnu' '--prefix=3D/usr' '--sharedstatedir=3D/var/lib' >>> '--libexecdir=3D/usr/lib' '--localstatedir=3D/var' '--infodir=3D/usr/sh= are/info' >>> '--mandir=3D/usr/share/man' >> '--with-pop=3Dyes' >> '--enable-locallisppath=3D/etc/emacs-snapshot:/etc/emacs:/usr/local/shar= e/emacs/23.0.90/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs= /23.0.90/site-lisp:/usr/share/emacs/site-lisp' >> '--with-x=3Dyes' '--with-x-toolkit=3Dgtk' 'build_alias=3Di486-linux-gnu'= 'host_alias=3Di486-linux-gnu' 'CFLAGS=3D-DDEBIAN -DSITELOAD_PURESIZE_EXTRA= =3D5000 -g -O2' 'LDFLAGS=3D-g -Wl,--as-needed' 'CPPFLAGS=3D'' From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 24 23:19:18 2016 Received: (at 2491) by debbugs.gnu.org; 25 Jan 2016 04:19:18 +0000 Received: from localhost ([127.0.0.1]:35358 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNYcX-0000vc-Vq for submit@debbugs.gnu.org; Sun, 24 Jan 2016 23:19:18 -0500 Received: from smtp61.avvanta.com ([206.124.128.61]:34920 helo=mail.avvanta.com) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNYcW-0000vT-7t for 2491@debbugs.gnu.org; Sun, 24 Jan 2016 23:19:16 -0500 Received: from mail.avvanta.com (localhost.rowlf.p [127.0.0.1]) by mail.avvanta.com (Postfix) with ESMTP id 2140993C8A; Sun, 24 Jan 2016 20:19:15 -0800 (PST) Received: from priss.frightenedpiglet.com (c-98-225-51-194.hsd1.wa.comcast.net [98.225.51.194]) by mail.avvanta.com (Postfix) with ESMTP id 03CC593C40; Sun, 24 Jan 2016 20:19:14 -0800 (PST) Received: from localhost ([127.0.0.1] helo=priss.frightenedpiglet.com) by priss.frightenedpiglet.com with esmtp (Exim 4.86) (envelope-from ) id 1aNYcP-000052-Ae; Sun, 24 Jan 2016 20:19:09 -0800 References: <20090227041420.3646.qmail@priss.frightenedpiglet.com> <87io2vd0bq.fsf@priss.frightenedpiglet.com> User-agent: mu4e 0.9.16; emacs 25.0.50.1 From: Derek Upham To: Andrew Hyatt Subject: Re: bug#2491: 23.0.90; Flymake too aggressive when responding to unusual error combination In-reply-to: Date: Sun, 24 Jan 2016 20:19:09 -0800 Message-ID: <87zivuguki.fsf@priss.frightenedpiglet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BlargAV-Status: No viruses detected, BlargAV v1.1 on localhost.scooter.p.blarg.net X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 2491 Cc: 2491@debbugs.gnu.org, rfrancoise@debian.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) This many years down the line I’m not in a position to reproduce it, so just close it out as “can’t repro”. Thanks, Derek Andrew Hyatt writes: > Got it. So, if I understand correctly, this may or may not be fixed, > but in any case, it seems specific to Erlang. Hopefully you, or another > Erlang user, can attempt to reproduce it so that we can move forward on > this bug. > > Derek Upham writes: > >> The situation is a flymake check for “foo.c”, where “foo.c” is perfectly fine but it #includes “bar.h” which has a syntax error. >> >> Flymake triggers a compilation. The compilation fails due to the syntax error, returning a non-zero exit status, along with the text >> >> bar.h:30: error: Invalid syntax >> >> Flymake quietly drops any error messages that refer to anything other than “foo.c”. As far as it is concerned, the above error output is empty. That means... >> >> - The error and warning counts are zero >> - The exit status is non-zero >> - The check was not interrupted >> >> The nested ‘if’ clauses in ‘flymake-post-syntax-check’ route control through: >> >> (flymake-report-fatal-status "CFGERR" >> (format "Configuration error has occured while running %s" command)) >> >> This code reports a fatal error and permanently turns off Flymake in the buffer. After you fix the syntax error in “bar.h”, you have to restart Flymake in “foo.c” (and any other files that depended on it). The bug is that we need to explicitly restart Flymake. >> >> The proposed solution in the bug report is to treat this case as a non-fatal situation, with a special mode line tag to indicate “there’s a deeper problem”. (It would be great if we could point the user to an error in “bar.h” line 30, but I don’t think there’s a good way to do it in the UI.) Upon reflection, I think it’s better for Flymake to keep counts of errors and warnings in “other” files (not ignore them) and use that to improve the post-syntax-check tests with another “if” clause. >> >> (I’m pretty sure this was with Erlang code, which is why no one else has encountered the bug. As I recall, GCC provides enough breadcrumbs that the #include line in the .c file will be tagged as a problem. The Erlang compiler doesn’t show that information, or didn’t back then.) >> >> Derek >> >> ahyatt@gmail.com writes: >> >>> Thanks for the bug report, and sorry it's sat so long without any >>> movement. Looking over this, I don't particularly understand the issue >>> (why would the check return a non-zero exit status if it was working >>> properly?) It might help if you provided a simple example. >>> >>> I've looked at the code in Emacs 25, though, and it still has the logic >>> you report. >>> >>> sand@blarg.net writes: >>> >>>> Background >>>> ---------- >>>> >>>> The Flymake library shipped with CVS HEAD (and probably earlier) has >>>> the following code in `flymake-post-syntax-check': >>>> >>>> (defun flymake-post-syntax-check (exit-status command) >>>> ;; [. . . elided . . .] >>>> >>>> (if (and (equal 0 err-count) (equal 0 warn-count)) >>>> (if (equal 0 exit-status) >>>> (flymake-report-status "" "") ; PASSED >>>> (if (not flymake-check-was-interrupted) >>>> (flymake-report-fatal-status "CFGERR" >>>> (format "Configuration error has occured while running %s" command)) >>>> (flymake-report-status nil ""))) ; "STOPPED" >>>> (flymake-report-status (format "%d/%d" err-count warn-count) ""))) >>>> >>>> Depending on... >>>> >>>> ...whether the flymake check generated errors or warnings, >>>> ...whether the flymake check had a non-zero exit status, and >>>> ...whether we interrupted the flymake check, >>>> >>>> we can generate any of four different statuses. One of the statuses, >>>> "CFGERR" is fatal, and turns off flymake for that buffer. The others >>>> are non-fatal. >>>> >>>> Problem >>>> ------- >>>> >>>> Flymake only tracks errors that refer to the specific file being >>>> checked. For example, given the following output for "foo.c", >>>> which includes file "bar.h" >>>> >>>> foo.c:20: warning: Type mismatch >>>> bar.h:30: error: Invalid syntax >>>> >>>> Flymake would "see" one warning and no errors. The "bar.h" error is >>>> dropped. Now consider the degenerate case where "bar.h" is the only >>>> source of errors, *and the check returns a non-zero exit status*: >>>> >>>> bar.h:30: error: Invalid syntax >>>> >>>> The error and warning counts are zero, the exit status is non-zero, >>>> the check was not interrupted, so we end up reporting a fatal CFGERR. >>>> >>>> Think aobut the user experience here, with the two examples shown >>>> above. First, Flymake checks, and reports an warning in the current >>>> file "foo.c". The user fixes the warning. Then Flymake reports a >>>> fatal error (popping up a dialog box under X) and turns itself off! >>>> >>>> Solution >>>> -------- >>>> >>>> That particular code branch is supposed to catch cases where the build >>>> system itself dies with an error, which is important to detect. But >>>> shutting down Flymake is too excessive a response, because of errors >>>> in included files. >>>> >>>> The following replacement code changes the behavior to report zero >>>> errors and zero warnings with the file itself, but it adds a ":CFGERR" >>>> flag to indicate that there was some other problem with the check. >>>> Flymake remains enabled for the buffer. >>>> >>>> (defun flymake-post-syntax-check (exit-status command) >>>> ;; [. . . elided . . .] >>>> >>>> (if (and (equal 0 err-count) (equal 0 warn-count)) >>>> (if (equal 0 exit-status) >>>> (flymake-report-status "" "") ; PASSED >>>> (if (not flymake-check-was-interrupted) >>>> (flymake-report-status "0/0" ":CFGERR") >>>> (flymake-report-status nil ""))) ; "STOPPED" >>>> (flymake-report-status (format "%d/%d" err-count warn-count) ""))) >>>> >>>> >>>> Derek >>>> >>>> >>>> >>>> >>>> In GNU Emacs 23.0.90.1 (i486-pc-linux-gnu, GTK+ Version 2.12.11) >>>> of 2009-02-07 on elegiac, modified by Debian >>>> (emacs-snapshot package, version 1:20090207-1) >>>> Windowing system distributor `The X.Org Foundation', version 11.0.10402000 >>>> configured using `configure '--build' 'i486-linux-gnu' '--host' >>>> 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' >>>> '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' >>>> '--mandir=/usr/share/man' >>> '--with-pop=yes' >>> '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/23.0.90/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.0.90/site-lisp:/usr/share/emacs/site-lisp' >>> '--with-x=yes' '--with-x-toolkit=gtk' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2' 'LDFLAGS=-g -Wl,--as-needed' 'CPPFLAGS='' -- Derek Upham sand@blarg.net From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 24 23:22:55 2016 Received: (at 2491) by debbugs.gnu.org; 25 Jan 2016 04:22:55 +0000 Received: from localhost ([127.0.0.1]:35362 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNYg2-00010r-Jw for submit@debbugs.gnu.org; Sun, 24 Jan 2016 23:22:55 -0500 Received: from mail-vk0-f48.google.com ([209.85.213.48]:33582) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNYg0-00010e-R0 for 2491@debbugs.gnu.org; Sun, 24 Jan 2016 23:22:53 -0500 Received: by mail-vk0-f48.google.com with SMTP id e64so68369703vkg.0 for <2491@debbugs.gnu.org>; Sun, 24 Jan 2016 20:22:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=RDxIrPZORAsf+LpZqB2MCboeX7YOAPD/pKatPEfqor8=; b=QfJ3oIyPKFdVtgUiehEFBr4Ao3X5pcYtZbeMpah6ZybMnqh60Ld2kNFCvDd8IHhlcU iERqQZXYo9JKWknXPtxBgB37XVpC2c2raflCcN64NrX+c4Ruf/DgseM2SC72Zn9K0sgR AMqOLlu26Zq5Sz8BpDUmhBxbmzFpsM7HjHHzD4duHd3sRiCxHqH7RLVpCSxgJmppHAl+ sfHwGkx4Lq4dRzfkzS111cPu0NUicvY+se/y7gQ/LZUm/X+g28hEyY0bF58kSACWm7ny uvYSc5+rx9Vh+7EUlnKQaO5OyIIIpZG1zLe3MgsWdSdBDio0s0/gwFnOx7oyVQBx7V/N /kBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=RDxIrPZORAsf+LpZqB2MCboeX7YOAPD/pKatPEfqor8=; b=AybDy0SOsigVzZwSnghVhJNpcY3bf1/etqtqxv8UDlMRAesYpVim2Da9UD6EhVXqm7 kaJaIu+QWG1+9PqHrBMaGIMzmZ754eSG3QyMkc7sJveZE5mR+KjS4Xx4GidGavFcG5+l ne7sDH7KhPf+heZec4jWBNDKNohl5SyzDM2HnL9itqMA3y0SQLgjyUR6nN4WmjQPbh82 R5SokZ+ob6IYXJdNPlEIy+ziDlo8UdaXWoCudoF0x9HMMCyeVUImRAvjJygk6dsR6Rih Z+gYh8EJiaq+pQKHvGJXjLjmeUapoDdDmpw0FkZwhUYyC4KmtfUi6J1/6GC6OqWOSs9s eZoQ== X-Gm-Message-State: AG10YOQWVlZW4HrtoKIi+ZB63EmY3x5JSJbowg13AmFj6MVGJX6c2GK89Fkqr0HPPjQym5gRsRId76NekM85qA== X-Received: by 10.31.47.200 with SMTP id v191mr10043647vkv.116.1453695767215; Sun, 24 Jan 2016 20:22:47 -0800 (PST) MIME-Version: 1.0 References: <20090227041420.3646.qmail@priss.frightenedpiglet.com> <87io2vd0bq.fsf@priss.frightenedpiglet.com> <87zivuguki.fsf@priss.frightenedpiglet.com> In-Reply-To: <87zivuguki.fsf@priss.frightenedpiglet.com> From: Andrew Hyatt Date: Mon, 25 Jan 2016 04:22:36 +0000 Message-ID: Subject: Re: bug#2491: 23.0.90; Flymake too aggressive when responding to unusual error combination To: Derek Upham Content-Type: multipart/alternative; boundary=001a1143fae0d10504052a20eba3 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 2491 Cc: 2491@debbugs.gnu.org, rfrancoise@debian.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a1143fae0d10504052a20eba3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Derek. On Sun, Jan 24, 2016 at 11:19 PM Derek Upham wrote: > This many years down the line I=E2=80=99m not in a position to reproduce = it, so > just close it out as =E2=80=9Ccan=E2=80=99t repro=E2=80=9D. > > Thanks, > > Derek > > Andrew Hyatt writes: > > > Got it. So, if I understand correctly, this may or may not be fixed, > > but in any case, it seems specific to Erlang. Hopefully you, or anothe= r > > Erlang user, can attempt to reproduce it so that we can move forward on > > this bug. > > > > Derek Upham writes: > > > >> The situation is a flymake check for =E2=80=9Cfoo.c=E2=80=9D, where = =E2=80=9Cfoo.c=E2=80=9D is > perfectly fine but it #includes =E2=80=9Cbar.h=E2=80=9D which has a synta= x error. > >> > >> Flymake triggers a compilation. The compilation fails due to the > syntax error, returning a non-zero exit status, along with the text > >> > >> bar.h:30: error: Invalid syntax > >> > >> Flymake quietly drops any error messages that refer to anything other > than =E2=80=9Cfoo.c=E2=80=9D. As far as it is concerned, the above error= output is empty. > That means... > >> > >> - The error and warning counts are zero > >> - The exit status is non-zero > >> - The check was not interrupted > >> > >> The nested =E2=80=98if=E2=80=99 clauses in =E2=80=98flymake-post-synta= x-check=E2=80=99 route control > through: > >> > >> (flymake-report-fatal-status "CFGERR" > >> (format "Configuration error has occured while running %s" command)) > >> > >> This code reports a fatal error and permanently turns off Flymake in > the buffer. After you fix the syntax error in =E2=80=9Cbar.h=E2=80=9D, y= ou have to restart > Flymake in =E2=80=9Cfoo.c=E2=80=9D (and any other files that depended on = it). The bug is > that we need to explicitly restart Flymake. > >> > >> The proposed solution in the bug report is to treat this case as a > non-fatal situation, with a special mode line tag to indicate =E2=80=9Cth= ere=E2=80=99s a > deeper problem=E2=80=9D. (It would be great if we could point the user t= o an error > in =E2=80=9Cbar.h=E2=80=9D line 30, but I don=E2=80=99t think there=E2=80= =99s a good way to do it in the > UI.) Upon reflection, I think it=E2=80=99s better for Flymake to keep co= unts of > errors and warnings in =E2=80=9Cother=E2=80=9D files (not ignore them) an= d use that to > improve the post-syntax-check tests with another =E2=80=9Cif=E2=80=9D cla= use. > >> > >> (I=E2=80=99m pretty sure this was with Erlang code, which is why no on= e else > has encountered the bug. As I recall, GCC provides enough breadcrumbs th= at > the #include line in the .c file will be tagged as a problem. The Erlang > compiler doesn=E2=80=99t show that information, or didn=E2=80=99t back th= en.) > >> > >> Derek > >> > >> ahyatt@gmail.com writes: > >> > >>> Thanks for the bug report, and sorry it's sat so long without any > >>> movement. Looking over this, I don't particularly understand the issu= e > >>> (why would the check return a non-zero exit status if it was working > >>> properly?) It might help if you provided a simple example. > >>> > >>> I've looked at the code in Emacs 25, though, and it still has the log= ic > >>> you report. > >>> > >>> sand@blarg.net writes: > >>> > >>>> Background > >>>> ---------- > >>>> > >>>> The Flymake library shipped with CVS HEAD (and probably earlier) has > >>>> the following code in `flymake-post-syntax-check': > >>>> > >>>> (defun flymake-post-syntax-check (exit-status command) > >>>> ;; [. . . elided . . .] > >>>> > >>>> (if (and (equal 0 err-count) (equal 0 warn-count)) > >>>> (if (equal 0 exit-status) > >>>> (flymake-report-status "" "") ; PASSED > >>>> (if (not flymake-check-was-interrupted) > >>>> (flymake-report-fatal-status "CFGERR" > >>>> (format "Configuration error has occured while running %s" command)) > >>>> (flymake-report-status nil ""))) ; "STOPPED" > >>>> (flymake-report-status (format "%d/%d" err-count warn-count) ""))) > >>>> > >>>> Depending on... > >>>> > >>>> ...whether the flymake check generated errors or warnings, > >>>> ...whether the flymake check had a non-zero exit status, and > >>>> ...whether we interrupted the flymake check, > >>>> > >>>> we can generate any of four different statuses. One of the statuses, > >>>> "CFGERR" is fatal, and turns off flymake for that buffer. The others > >>>> are non-fatal. > >>>> > >>>> Problem > >>>> ------- > >>>> > >>>> Flymake only tracks errors that refer to the specific file being > >>>> checked. For example, given the following output for "foo.c", > >>>> which includes file "bar.h" > >>>> > >>>> foo.c:20: warning: Type mismatch > >>>> bar.h:30: error: Invalid syntax > >>>> > >>>> Flymake would "see" one warning and no errors. The "bar.h" error is > >>>> dropped. Now consider the degenerate case where "bar.h" is the only > >>>> source of errors, *and the check returns a non-zero exit status*: > >>>> > >>>> bar.h:30: error: Invalid syntax > >>>> > >>>> The error and warning counts are zero, the exit status is non-zero, > >>>> the check was not interrupted, so we end up reporting a fatal CFGERR= . > >>>> > >>>> Think aobut the user experience here, with the two examples shown > >>>> above. First, Flymake checks, and reports an warning in the current > >>>> file "foo.c". The user fixes the warning. Then Flymake reports a > >>>> fatal error (popping up a dialog box under X) and turns itself off! > >>>> > >>>> Solution > >>>> -------- > >>>> > >>>> That particular code branch is supposed to catch cases where the bui= ld > >>>> system itself dies with an error, which is important to detect. But > >>>> shutting down Flymake is too excessive a response, because of errors > >>>> in included files. > >>>> > >>>> The following replacement code changes the behavior to report zero > >>>> errors and zero warnings with the file itself, but it adds a ":CFGER= R" > >>>> flag to indicate that there was some other problem with the check. > >>>> Flymake remains enabled for the buffer. > >>>> > >>>> (defun flymake-post-syntax-check (exit-status command) > >>>> ;; [. . . elided . . .] > >>>> > >>>> (if (and (equal 0 err-count) (equal 0 warn-count)) > >>>> (if (equal 0 exit-status) > >>>> (flymake-report-status "" "") ; PASSED > >>>> (if (not flymake-check-was-interrupted) > >>>> (flymake-report-status "0/0" ":CFGERR") > >>>> (flymake-report-status nil ""))) ; "STOPPED" > >>>> (flymake-report-status (format "%d/%d" err-count warn-count) ""))) > >>>> > >>>> > >>>> Derek > >>>> > >>>> > >>>> > >>>> > >>>> In GNU Emacs 23.0.90.1 (i486-pc-linux-gnu, GTK+ Version 2.12.11) > >>>> of 2009-02-07 on elegiac, modified by Debian > >>>> (emacs-snapshot package, version 1:20090207-1) > >>>> Windowing system distributor `The X.Org Foundation', version > 11.0.10402000 > >>>> configured using `configure '--build' 'i486-linux-gnu' '--host' > >>>> 'i486-linux-gnu' '--prefix=3D/usr' '--sharedstatedir=3D/var/lib' > >>>> '--libexecdir=3D/usr/lib' '--localstatedir=3D/var' > '--infodir=3D/usr/share/info' > >>>> '--mandir=3D/usr/share/man' > >>> '--with-pop=3Dyes' > >>> > '--enable-locallisppath=3D/etc/emacs-snapshot:/etc/emacs:/usr/local/share= /emacs/23.0.90/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/= 23.0.90/site-lisp:/usr/share/emacs/site-lisp' > >>> '--with-x=3Dyes' '--with-x-toolkit=3Dgtk' 'build_alias=3Di486-linux-g= nu' > 'host_alias=3Di486-linux-gnu' 'CFLAGS=3D-DDEBIAN -DSITELOAD_PURESIZE_EXTR= A=3D5000 > -g -O2' 'LDFLAGS=3D-g -Wl,--as-needed' 'CPPFLAGS=3D'' > > > -- > Derek Upham > sand@blarg.net > --001a1143fae0d10504052a20eba3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Derek.

On Sun, Jan 24, 2016 at 11:19 PM Derek Upham <sand@blarg.net> wrote:
This many years down the line I=E2=80=99m not in a position t= o reproduce it, so just close it out as =E2=80=9Ccan=E2=80=99t repro=E2=80= =9D.

Thanks,

Derek

Andrew Hyatt writes:

> Got it.=C2=A0 So, if I understand correctly, this may or may not be fi= xed,
> but in any case, it seems specific to Erlang.=C2=A0 Hopefully you, or = another
> Erlang user, can attempt to reproduce it so that we can move forward o= n
> this bug.
>
> Derek Upham <sa= nd@blarg.net> writes:
>
>> The situation is a flymake check for =E2=80=9Cfoo.c=E2=80=9D, wher= e =E2=80=9Cfoo.c=E2=80=9D is perfectly fine but it #includes =E2=80=9Cbar.h= =E2=80=9D which has a syntax error.
>>
>> Flymake triggers a compilation.=C2=A0 The compilation fails due to= the syntax error, returning a non-zero exit status, along with the text >>
>>=C2=A0 =C2=A0bar.h:30: error: Invalid syntax
>>
>> Flymake quietly drops any error messages that refer to anything ot= her than =E2=80=9Cfoo.c=E2=80=9D.=C2=A0 As far as it is concerned, the abov= e error output is empty.=C2=A0 That means...
>>
>> - The error and warning counts are zero
>> - The exit status is non-zero
>> - The check was not interrupted
>>
>> The nested =E2=80=98if=E2=80=99 clauses in =E2=80=98flymake-post-s= yntax-check=E2=80=99 route control through:
>>
>>=C2=A0 (flymake-report-fatal-status "CFGERR"
>>=C2=A0 =C2=A0(format "Configuration error has occured while ru= nning %s" command))
>>
>> This code reports a fatal error and permanently turns off Flymake = in the buffer.=C2=A0 After you fix the syntax error in =E2=80=9Cbar.h=E2=80= =9D, you have to restart Flymake in =E2=80=9Cfoo.c=E2=80=9D (and any other = files that depended on it).=C2=A0 The bug is that we need to explicitly res= tart Flymake.
>>
>> The proposed solution in the bug report is to treat this case as a= non-fatal situation, with a special mode line tag to indicate =E2=80=9Cthe= re=E2=80=99s a deeper problem=E2=80=9D.=C2=A0 (It would be great if we coul= d point the user to an error in =E2=80=9Cbar.h=E2=80=9D line 30, but I don= =E2=80=99t think there=E2=80=99s a good way to do it in the UI.)=C2=A0 Upon= reflection, I think it=E2=80=99s better for Flymake to keep counts of erro= rs and warnings in =E2=80=9Cother=E2=80=9D files (not ignore them) and use = that to improve the post-syntax-check tests with another =E2=80=9Cif=E2=80= =9D clause.
>>
>> (I=E2=80=99m pretty sure this was with Erlang code, which is why n= o one else has encountered the bug.=C2=A0 As I recall, GCC provides enough = breadcrumbs that the #include line in the .c file will be tagged as a probl= em.=C2=A0 The Erlang compiler doesn=E2=80=99t show that information, or did= n=E2=80=99t back then.)
>>
>> Derek
>>
>> ahyatt@gmail= .com writes:
>>
>>> Thanks for the bug report, and sorry it's sat so long with= out any
>>> movement. Looking over this, I don't particularly understa= nd the issue
>>> (why would the check return a non-zero exit status if it was w= orking
>>> properly?) It might help if you provided a simple example.
>>>
>>> I've looked at the code in Emacs 25, though, and it still = has the logic
>>> you report.
>>>
>>> sand@blarg= .net writes:
>>>
>>>> Background
>>>> ----------
>>>>
>>>> The Flymake library shipped with CVS HEAD (and probably ea= rlier) has
>>>> the following code in `flymake-post-syntax-check':
>>>>
>>>> (defun flymake-post-syntax-check (exit-status command)
>>>> ;; [. . . elided . . .]
>>>>
>>>> (if (and (equal 0 err-count) (equal 0 warn-count))
>>>> (if (equal 0 exit-status)
>>>> (flymake-report-status "" "") ; PASSED=
>>>> (if (not flymake-check-was-interrupted)
>>>> (flymake-report-fatal-status "CFGERR"
>>>> (format "Configuration error has occured while runnin= g %s" command))
>>>> (flymake-report-status nil ""))) ; "STOPPED= "
>>>> (flymake-report-status (format "%d/%d" err-count= warn-count) "")))
>>>>
>>>> Depending on...
>>>>
>>>> ...whether the flymake check generated errors or warnings,=
>>>> ...whether the flymake check had a non-zero exit status, a= nd
>>>> ...whether we interrupted the flymake check,
>>>>
>>>> we can generate any of four different statuses. One of the= statuses,
>>>> "CFGERR" is fatal, and turns off flymake for tha= t buffer. The others
>>>> are non-fatal.
>>>>
>>>> Problem
>>>> -------
>>>>
>>>> Flymake only tracks errors that refer to the specific file= being
>>>> checked. For example, given the following output for "= ;foo.c",
>>>> which includes file "bar.h"
>>>>
>>>> foo.c:20: warning: Type mismatch
>>>> bar.h:30: error: Invalid syntax
>>>>
>>>> Flymake would "see" one warning and no errors. T= he "bar.h" error is
>>>> dropped. Now consider the degenerate case where "bar.= h" is the only
>>>> source of errors, *and the check returns a non-zero exit s= tatus*:
>>>>
>>>> bar.h:30: error: Invalid syntax
>>>>
>>>> The error and warning counts are zero, the exit status is = non-zero,
>>>> the check was not interrupted, so we end up reporting a fa= tal CFGERR.
>>>>
>>>> Think aobut the user experience here, with the two example= s shown
>>>> above. First, Flymake checks, and reports an warning in th= e current
>>>> file "foo.c". The user fixes the warning. Then F= lymake reports a
>>>> fatal error (popping up a dialog box under X) and turns it= self off!
>>>>
>>>> Solution
>>>> --------
>>>>
>>>> That particular code branch is supposed to catch cases whe= re the build
>>>> system itself dies with an error, which is important to de= tect. But
>>>> shutting down Flymake is too excessive a response, because= of errors
>>>> in included files.
>>>>
>>>> The following replacement code changes the behavior to rep= ort zero
>>>> errors and zero warnings with the file itself, but it adds= a ":CFGERR"
>>>> flag to indicate that there was some other problem with th= e check.
>>>> Flymake remains enabled for the buffer.
>>>>
>>>> (defun flymake-post-syntax-check (exit-status command)
>>>> ;; [. . . elided . . .]
>>>>
>>>> (if (and (equal 0 err-count) (equal 0 warn-count))
>>>> (if (equal 0 exit-status)
>>>> (flymake-report-status "" "") ; PASSED=
>>>> (if (not flymake-check-was-interrupted)
>>>> (flymake-report-status "0/0" ":CFGERR"= )
>>>> (flymake-report-status nil ""))) ; "STOPPED= "
>>>> (flymake-report-status (format "%d/%d" err-count= warn-count) "")))
>>>>
>>>>
>>>> Derek
>>>>
>>>>
>>>>
>>>>
>>>> In GNU Emacs 23.0.90.1 (i486-pc-linux-gnu, GTK+ Version 2.= 12.11)
>>>> of 2009-02-07 on elegiac, modified by Debian
>>>> (emacs-snapshot package, version 1:20090207-1)
>>>> Windowing system distributor `The X.Org Foundation', v= ersion 11.0.10402000
>>>> configured using `configure '--build' 'i486-li= nux-gnu' '--host'
>>>> 'i486-linux-gnu' '--prefix=3D/usr' '--= sharedstatedir=3D/var/lib'
>>>> '--libexecdir=3D/usr/lib' '--localstatedir=3D/= var' '--infodir=3D/usr/share/info'
>>>> '--mandir=3D/usr/share/man'
>>> '--with-pop=3Dyes'
>>> '--enable-locallisppath=3D/etc/emacs-snapshot:/etc/emacs:/= usr/local/share/emacs/23.0.90/site-lisp:/usr/local/share/emacs/site-lisp:/u= sr/share/emacs/23.0.90/site-lisp:/usr/share/emacs/site-lisp'
>>> '--with-x=3Dyes' '--with-x-toolkit=3Dgtk' '= ;build_alias=3Di486-linux-gnu' 'host_alias=3Di486-linux-gnu' &#= 39;CFLAGS=3D-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=3D5000 -g -O2' 'LDFL= AGS=3D-g -Wl,--as-needed' 'CPPFLAGS=3D''


--
Derek Upham
sand@blarg.net
--001a1143fae0d10504052a20eba3-- From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 24 23:23:07 2016 Received: (at control) by debbugs.gnu.org; 25 Jan 2016 04:23:07 +0000 Received: from localhost ([127.0.0.1]:35366 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNYgE-00011q-AL for submit@debbugs.gnu.org; Sun, 24 Jan 2016 23:23:07 -0500 Received: from mail-qg0-f43.google.com ([209.85.192.43]:34363) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNYgD-000113-DS for control@debbugs.gnu.org; Sun, 24 Jan 2016 23:23:05 -0500 Received: by mail-qg0-f43.google.com with SMTP id 6so100157098qgy.1 for ; Sun, 24 Jan 2016 20:23:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:message-id:to:from:subject; bh=OLxju+Cn0IJmBH+bxW+9719JTY3JtLISihx19fDK95s=; b=M9Hng8HHKo18laERZgkaYEfLDMZw0Rf8IKZXBPKfMelhqAelYdnfyM0Oo0ap2JTn0p HsQIuHR8gFGCQVDN15rbgy0HrlWhvQgvo/mLJ8lj9DnRJPOkOp0LcNxUj3YIn/FESVbA gckI/dybzO0yXwdrl+Czi8XMhYoY5yaWDCk5dXaVed0MHsVGbNS7dRAA7eijdjxawVQs Fm8DOzZcKq1U5lv6rMGFS0ACus3+drIlc+vXDN8aJU95DKRCg7mOymg7uvl+abOuYDgu lGCfcvc16AqA3Z0oD/MqoztykyMNVQ/pxU1s8+swLJ2sVqfZu++FrDcJe4vs7umpph0s 6NxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:message-id:to:from:subject; bh=OLxju+Cn0IJmBH+bxW+9719JTY3JtLISihx19fDK95s=; b=m8Xrx7PQ/+Ko3trFNVUjEiOAQBn6XB9I11DGDaKvk+ymmHUjg8AGMZHagL5+owpTo4 iIWXwZ6qWQ19DWMmvh02fUlqh/q4Ca7EnjGEmcTG4bA5D6sv5ziGx4vCdzeT7pgRpLj0 oILZHttcfVaV+XIpOtQGW/c3GEygodmBsxcCIj9uOElX71SSAVQSAnhZFOsdNmiP/Wr9 ru8a1TUAYF96C+uM7gzvtC58tq2s1BoXHWXCU0F6SzkTdBIZDkmzGj9A6NWAxCxOV722 ZSgwtEBqy7hOVA23uRtTgEx+zufe7p/5wHRubz7uZfThgWHaOx09kRVFCcGOxyUZqwuQ 8siA== X-Gm-Message-State: AG10YOTSZ7LrtUpmSmDXH0xSB0+zaBIj1P6pg8tfxcScgAnNE/2YLb+SFDBgAtUgkRavHA== X-Received: by 10.140.152.18 with SMTP id 18mr19082070qhy.16.1453695779847; Sun, 24 Jan 2016 20:22:59 -0800 (PST) Received: from Andrews-MacBook-Pro.local.ahyatt-laptop (cpe-74-73-128-199.nyc.res.rr.com. [74.73.128.199]) by smtp.gmail.com with ESMTPSA id r6sm8045475qhr.28.2016.01.24.20.22.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Jan 2016 20:22:59 -0800 (PST) Date: Sun, 24 Jan 2016 23:22:57 -0500 Message-Id: To: control@debbugs.gnu.org From: Andrew Hyatt Subject: control message for bug #2491 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) tags 2491 unreproducible close 2491 From unknown Tue Jun 24 13:56:40 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 22 Feb 2016 12:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator