As a Fortran user/developer, when you use Fortran compilers:
-fmax-errors=1 in GFortran)?0 voters
I prefer to get all of them, because on occasion the first error is not the cause of the problem. Of course if youâre compiling and testing frequently enough that shouldnât be a problem 
What is an example where the first error is not the cause of the problem?
Some compilers cannot proceed to the next analysis phase (which might uncover more errors) until the earlier phase is error-free. So, the user fixes the indicated errors only to find yet more! Not ideal, but pretty inevitable.
I donât remember a specific example when this happened. Itâs pretty rare. I think I may have seen something like misspelling the name on an end function name but then the first error reported was unexpected end of module.
If you use compiler options that treat certain warnings as errors, the first âerrorâ may not cause the other errors. I have Windows cmd scripts that print âerrorsâ of a certain type, for example
@ echo off
:: list unused variables in Fortran source file, compiled with gfortran
:: usage: gfun.bat foo.f90
set gfout=temp_gf.txt
gfortran -c -Wall %1 2> %gfout%
:: echo unused variables:
grep Unused %gfout% | tr -d "'" | cut -d ' ' -f 4
and
@ echo off
:: list undeclared variables in Fortran source file, compiled with gfortran
:: usage: gfundec.bat foo.f90
setlocal
set gfout=temp_gf.txt
gfortran -c -Wall %1 2> %gfout%
echo undeclared in %1:
grep IMPLICIT %gfout% | tr -d "'" | cut -d ' ' -f 3
I use them when refactoring code.
Thatâs right â I actually stopped using -fmax-errors=1 for GFortran, because sometimes it didnât give sufficient information. I remember some issue when warnings are turned into errors. But it also sometimes happened that GFortran returned two error messages that describe that one error (perhaps two places in the file related to it), and -fmax-errors=1 only reported one, so it was no sufficient to know where the error was.
However, all these things I consider to be a bug in a compiler. I want a compiler to give me just one error message, but it needs to be a good one. So I voted âjust oneâ above.
Compilers can and do report on multiple unrelated errors besides errors that are consequences of preceding errors. A trained eye can pretty readily pick these out in the output. That allows one to go and fix multiple errors at once before recompiling. Thatâs a lot more efficient than fixing and recompiling one at a time. I voted âallâ.
I am not sure what do you mean by âthe problemâ. Nevertheless, not all errors come from cascading. I very often see errors originating from independent mistakes, even when warnings are treated separately. May be this partly due to the fact that I do not use any modern IDE or concurrent syntax analyzer, and instead depend on compiler for catching even the most mundane errors.
I was looking for an example of this behavior:
I prefer to get on the order of twenty of them. Not all error are from an error cascade, and its useful to get a representative sample In particular, I have an essential tremor and am particularly prone to typos. With about twenty all of them fit on on a page and I can fix a significant number of them without having to scroll back forever.
I tend to ask for just one error to avoid having to scroll back through pages of output, and then turn on multiple errors if the one error isnât very helpful.
I wonder if it would be possible to have the best of both worlds: store all the errors until whatever the abort condition is (e.g. the end of the file with the first error), and then print them in reverse order, so the first error is right there without needing to scroll, and the later errors are on hand if theyâre useful.
I guess it would also be nice if the errors could be grouped by type, so e.g. instead of having to pick out the undefined variables (usually typos) from a list of other errors, they could all be in a single list.
I voted all for the same reason as @nncarlson. It is more efficient to fix multiple errors before recompiling.
For a small Fortran project (500 lines) I will typically get a few dozen errors, forgetting to declare variables, or getting the call sequences wrong. I like to see the error messages shrink as I recompile after fixing batches of 1 to 10 errors. I will often use Ctrl + g + <line number> in my text editor to jump directly to the affected line.
If I get in a situation where the compiler is printing a huge amount of errors, Iâll use âclearâ on the terminal, then compile and be able to scroll and stop automatically at the top.
One example is for a program unit for which IMPLICIT NONE is in effect (a good idea in general), and there are separate messages for each undeclared variable. Easier for me to deal with all the cases (often a typo in the spelling of the variable name in either the usage location or (worse) in the declaration). Faster to deal with all of them at once rather than recompiling for each one sequentially. [It is sometimes better for âallâ messages output to really mean all up to some limit, like 100, just to keep things manageable.]
My own scripts always compile to a log file and tee the output into a pager (ie. less(1) or more(1)) when a tty is detected. I set pager options so if screen is not filled no paging occurs; I have also used a line count limit
using head(1) instead. So if interactive get first page of errors and can quit if desired, or if a lot (like a lot of variables without a type) then everything is in a file I can edit. When I wrote the scripts some pagers had issues with saving or editing piped input and such so the file is often then already available to use in a separate window or can be used for other scripts to create a bunch of declarations using default implicit type assumptions, or grepped for line numbers, etc. So it is not that I want one error, I want one page. When making changes to existing codes I usually want one error at a time; when porting codes to new programming environments or adding new requirements like removing deprecated features, enforcing typing, identifying non-portable or non-standard usage, and so on I want all the messages. So ânone of the aboveâ, but when using the compiler commands directly I usually prefer 1 to 4 if working on something I know should not have any errors other than those recently introduced by rework or new feature development, I want âallâ in particular the first time I compile something with a new compiler or after making a change like adding âimplicit noneâ.
As an aside, with something like fpm I would like behavior something like that. If a new compile with no subdirectory in build/ (assuming a fresh compile means a new code or new options on the compile) I would like to see all the messages; if I just compiled a few minutes ago I typically one just one error; or at least < 4. Just revisited that with @lkedward a bit in a recent discussion. Still pondering it, but I think every latest build should write a logfile, and someone should make a plugin that lets you interact with the logfile to review it, or use it to invoke the editor at specified lines, open a www search for the error message, call a vendor âexplainâ utility, bring up a man-page on a routine, open up a vendor bug report or a discourse(1) discussion :> ⌠So fpm(1) would stay core-focused by IDE-like functions could be added; and all messages would be available without recompiling (which is usually not a very long operation, but for some circumstances can be very slow ).
If you have written error messages to a file and then print them, you may decide to stop displaying messages after certain types of errors are encountered, because later errors will result from them. Such âshowstopperâ errors include
use m, only: foo if foo is not found in m
function foo followed by end function bar, do followed by endif instead of enddo, labeled do loop closed by mislabeled enddo
What are some other showstoppers?
I usually compile with options that turn some warnings into errors. If a source file does not compile, I may recompile without such options and fix the true errors first. This procedure could be automated.
Btw, to ensure that error messages are independent (i.e., that the first is not the cause of the other ones), one approach to do that is to âpoisonâ the AST tree from the error node all the way up, and only show other errors if they come from a not yet poisoned AST node. As an example if there is a type mismatch error in an expression, then one can poison the whole subroutine and anything that calls it. But if there is another subroutine (definitely in a separate module, but probably also in the same module) that also has a type mismatch error, then that can be reported.
If one is aggressive with âpoisoningâ, I think one can achieve quite good independent error messages.
For example, if a function call is not declared inside a subroutine, one could assume that the module is missing a use statement, so one can poison everything in the module. So any other missing functions would not be reported, because they could presumably come from the same missing used module.
However, as several people commented above, they actually like if the compiler reports all undeclared variables (and functions I assume) even in the same module I guess. So even if theoretically all such errors might be caused by the âfirst errorâ (which is caused by one missing use statement), in practice they might not.
This is a tough problem.
I was quite surprised seeing that when GFortran showed multiple error messages (quite new to FORTRAN). But then, overall Iâve not been really happy with the quality of error messages, it just happens to be the case that the other error messages arenât gonna be any relevant at all, if the first one is actually fixed.
As a beginner itâs a little daunting to look at them all at once, but once you get used to it, it helps.
Also, its nice that weâve the option to turn off the rest of the error messages by using -fmax-errors=1.
It depends on the first error. If it breaks the structure of the code (you forgot to close something like a parenthesis for example), the compiler is lost and will generate false alerts.
Probably it is surprising if you first learned interpreted languages where the interpreter is stopped immediately if it fails to translate a line of code.
Note that if you use fpm to build your Fortran project, its default behavior is to print only the first error message. But you can use the --verbose option for more.