bug#2491: 23.0.90; Flymake too aggressive when responding to unusual error combination

[Derek Upham]

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 <sand@blarg.net> 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