On Mon, Aug 3, 2009 at 12:43 AM, Nick Sabalausky<[email protected]> wrote:
> "Jarrett Billingsley" <[email protected]> wrote in message
> news:[email protected]...
>>
> I've often wondered about how useful parser recovery really is. Most
> of the time, parsing errors after the first are complete bull anyway,
> so the compiler's just filling up my console with garbage.
> <
>
> Frequently, yes, but I find that getting numerous *real* errors from one
> compile is also a frequent occurrance - and a real time saver. I get really
> annoyed when I get into a 5-10 iteration cycle of "fix the one reported
> error, recompile, get one more error, fix that, etc..."
>
>> If you
> combine that with the fact that recompiles are extremely cheap with D
> and modern machines,
> <
>
> That actual recompile is often (though not always) short, but the total
> programmer time is much higher. I find that the whole process goes *much*
> faster overall when I do get a bunch of real errors at once than when I just
> get one at a time.
Oh, I agree that multiple errors on a single compile is useful. But
multiple *parser* errors on a single compile is next to useless, since
the parser can very easily get confused at the beginning of some
malformed code and start throwing up all kinds of crap. Try this:
void foo()
{
bar() // no semicolon
}
DMD spits out a semicolon expected, followed by several useless "found
EOF instead of statement" errors at the end of the file. This is by
no means the only parser error BS, but it's the one I can think of off
the top of my head.
Once it's parsed, though, it's easy (and useful!) to flag multiple
semantic errors on a single compile.
