Re: Semantic error recovery

>[How many people find it useful for a compiler to chug through and try to
>parse and diagnose an entire file in the presence of errors? I'm just as
>happy with one that finds a few errors and gives up so I can go fix them.
>-John]


Depends on how you define "few". One of the overwhelming complaints about
the Think compilers (on the Mac) was that on finding the first error, they
would stop, throw you back into the editor, and point out the error. If
you define "few" as "one", lots of people would complain. Symantec
changed this for their C/C++ compilers v. 6.0. The problem now that I've
run across is that if I leave it in "find all errors" mode, the compiler
can get so confused by its own errors that it crashes. For certain areas
of the language, like the (admittedly buggy) templates implementation,
I've had to go back to "stop on first bug" mode.


To some extent, it seems a matter of taste, and also greatly depends on
how fast the compilation is. If it takes 40 seconds to load up all the
previous include files, and preprocess and expand templates and..., then I
tend to want "find all errors." If I'm doing something that compiles
quickly, I don't mind and would usually prefer seeing my errors one at a
time and know that they aren't spurious.


--Eric
--

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