Thanks, Derek. On Sun, Jan 24, 2016 at 11:19 PM Derek Upham wrote: > 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 >