Re: Improved accuracy in diagnostics. Is it worthwhile?

On 18/03/2022 20:12, Thomas Koenig wrote:
> ...
> If you are compiling, it is usually a small fraction of time that
> is spent in the parsing, and much more in optimization and code
> generation. An example: Compiling a 50 k line Fortran program with
> "gfortran -O2" takes 17.4 seconds on the computer I type this on.
> Checking with "gfortran -fsyntax-only" takes 4.2 seconds. (For
> those who want to reproduce: aermod.f90 from the Polyhedron suite).
> ...


Thanks. Just tested this large file and the runtime overhead seems
to be negligible.


Likely, I'll try the change but it took me a while to find another case
with enumerators (that also lack error recovery now). Although my trial
changes added messages for 43 states, some of them are useless and so
this approach seems to be useful for BNF rules with an optional tail.


Unavoidably, a parser/front-end has to make some guessing on error
and this doesn't change easily. So, any improvement without default
state reductions (hello Kaz) will be limited, as in the code below:




-----------------------------------------------------------------------


miniserver:errors suser$ cat enum-1.f90 && fcheck enum-1.f90
                  ENUM, BIND(C)
                    ENUMERATOR :: RED => 4, BLUE => 9
                    ENUMERATOR YELLOW
                  END ENUM
                  END
enum-1.f90:2: error: syntax:Unexpected: '=>'. Expected: ",", ";", or "=".


Parsed with Errors: enum-1.f90
miniserver:errors suser$

Return to the comp.compilers page.
Search the comp.compilers archives again.