Terminate parsing any single compilation unit if we encounter more then 100 parse errors.

Terminate parsing any single compilation unit if we encounter more then 100 parse errors.
Committed: https://code.google.com/p/dart/source/detail?r=9445

[devoncarew, 2012-07-02 22:57:13]

I'm not sure if we want to land this, but it significantly decreases the amount
of time it takes to parse a malformed file.

[danrubel, 2012-07-03 14:57:13]

LGTM. I think this is a reasonable fallback mechanism to prevent DartC from
becoming bogged down by a single malformed dart file.

[Brian Wilkerson, 2012-07-03 15:14:50]

I'm note sure whether this is the best place for this (it might be more
appropriate to move it into the context, for example), but I'm OK with leaving
it here and fixing it later if it proves to be the wrong choice.

The one thing that *really* needs fixed before this is committed is to make this
behavior be conditional based on a compiler option so that the command-line
analysis tool still has the ability to find all errors and warnings. We can
debate what the default behavior for the command line should be, but I would
lean toward leaving it's behavior unchanged by default.

http://codereview.chromium.org/10704068/diff/1/compiler/java/com/google/dart/...
File compiler/java/com/google/dart/compiler/parser/DartParser.java (right):

http://codereview.chromium.org/10704068/diff/1/compiler/java/com/google/dart/...
compiler/java/com/google/dart/compiler/parser/DartParser.java:4581: //
TODO(devoncarew): add a 'too many errors' error?
I would say yes, otherwise the user can't know that there are more errors that
we're not reporting.

[devoncarew, 2012-07-03 18:45:20]

I didn't see a clear way to plumb a flag through to control this behavior (from
the CompilerOptions / CompilerConfiguration objects). I'm not sure that several
thousand parse errors for one file make much more sense in the command-line
context then they do in the editor one. In any case, I think this behavior is an
improvement from the UX perspective.

I ran the dartc unit tests - they run through w/o issues.

PTAL -

http://codereview.chromium.org/10704068/diff/1/compiler/java/com/google/dart/...
File compiler/java/com/google/dart/compiler/parser/DartParser.java (right):

http://codereview.chromium.org/10704068/diff/1/compiler/java/com/google/dart/...
compiler/java/com/google/dart/compiler/parser/DartParser.java:4581: //
TODO(devoncarew): add a 'too many errors' error?
On 2012/07/03 15:14:50, Brian Wilkerson wrote:
> I would say yes, otherwise the user can't know that there are more errors that
> we're not reporting.

Done.

[Brian Wilkerson, 2012-07-03 19:07:52]

Aside from my comments, LGTM.

http://codereview.chromium.org/10704068/diff/3001/compiler/java/com/google/da...
File compiler/java/com/google/dart/compiler/parser/ParserErrorCode.java (right):

http://codereview.chromium.org/10704068/diff/3001/compiler/java/com/google/da...
compiler/java/com/google/dart/compiler/parser/ParserErrorCode.java:110: //
TODO(zundel): error message needs JUnit test
Eric didn't add this TODO, and I'm not sure I want a JUnit test for this case...

http://codereview.chromium.org/10704068/diff/3001/compiler/java/com/google/da...
compiler/java/com/google/dart/compiler/parser/ParserErrorCode.java:111:
NO_SOUP_FOR_YOU("Too many errors"),
Maybe we could call it something less humorous, like "TOO_MANY_ERRORS".

[devoncarew, 2012-07-03 20:45:14]

http://codereview.chromium.org/10704068/diff/3001/compiler/java/com/google/da...
File compiler/java/com/google/dart/compiler/parser/ParserErrorCode.java (right):

http://codereview.chromium.org/10704068/diff/3001/compiler/java/com/google/da...
compiler/java/com/google/dart/compiler/parser/ParserErrorCode.java:110: //
TODO(zundel): error message needs JUnit test
On 2012/07/03 19:07:53, Brian Wilkerson wrote:
> Eric didn't add this TODO, and I'm not sure I want a JUnit test for this
case...

Done - removed the TODO.