Prevent double reporting on hex, strings, and multiline comments.

tests/compiler/dart2js/message_kind_helper.dart

Index: tests/compiler/dart2js/message_kind_helper.dart
diff --git a/tests/compiler/dart2js/message_kind_helper.dart b/tests/compiler/dart2js/message_kind_helper.dart
index 5a16e5647be008e49853540fbfa61c2eef1e6c3b..4a925294b171963bccc85b0ad59160be73a303d6 100644
--- a/tests/compiler/dart2js/message_kind_helper.dart
+++ b/tests/compiler/dart2js/message_kind_helper.dart
@@ -40,10 +40,11 @@ final Set<MessageKind> kindsWithExtraMessages = new Set<MessageKind>.from([
     MessageKind.VAR_FUNCTION_TYPE_PARAMETER,
     MessageKind.VOID_NOT_ALLOWED,
 
-    MessageKind.HEX_DIGIT_EXPECTED, // http://dartbug.com/18574
     MessageKind.UNMATCHED_TOKEN, // http://dartbug.com/18574
-    MessageKind.UNTERMINATED_COMMENT, // http://dartbug.com/18574
-    MessageKind.UNTERMINATED_STRING, // http://dartbug.com/18574
+    /// Hard to avoid for multiline strings; there is no case where a multiline
+    /// string can be legitimately followed by EOM, so it is unavoidable that
+    /// the parser will expect a token to follow.
+    MessageKind.UNTERMINATED_STRING, // hard to avoid for multiline strings

[ahe, 2014/06/23 14:28:49]

Could you restore the bug number and remove the comment?

My suggested fix for an unterminated multi-line string is to synthesize a token
stream that gracefully ends the current element being parsed. The beginFoo calls
in the listener can be used for this.

Alternatively, the listener can stay silent after seeing an unterminated
multi-line string (or comment).

This makes me think, do we need a test for something like:

main() => /*

[srawlins, 2014/07/15 20:07:08]

Done.
This is the fix I implemented: gracefully end the current element. But then we
are at EOF, and so a ";" or a ")" or something is always expected. A multiline
string cannot be the last token in a file, unlike a multiline comment.
I could not see a way to do this...
That should be covered in the UNTERMINATED_COMMENT tests.

[ahe, 2014/07/16 07:54:18]

What you have implemented is the same pattern as is used elsewhere, so nothing
wrong with that.

However, what I mean by gracefully ending the current element is different from
skipping to EOF. I'd say skipping to EOF is rather crude, but gets the job done.

Consider this example:

main() {"""

What I'm suggesting in this case is that the listener returns this token stream
in response to the problem:

  ; } EOF

The listener could insert both the semicolon and the curly brace, and the parser
would recover (gracefully).

But I'm not suggesting that you do this, at least not in this CL. But it's what
I'd really like to get done before the above bugs are closed. If you find that
sort of thing interesting, I'd be happy to talk more about this.
I've recently implemented something like that. See
https://codereview.chromium.org/324293002/.
That test is slightly different because the comment is at top-level.

[srawlins, 2014/08/12 04:32:58]

Somehow this sorted itself out in the last few weeks. I merged master today and
UNTERMINATED_STRING does not double warn any more!

 ]);
 
 /// Most messages can be tested without causing a fatal error. Add an exception
@@ -60,7 +61,6 @@ final Set<MessageKind> kindsWithPendingClasses = new Set<MessageKind>.from([
 /// stop before analyzing all input, and it isn't safe to reuse it.
 final Set<MessageKind> kindsWithFatalErrors = new Set<MessageKind>.from([
     // If you add something here, please file a *new* bug report.
-    MessageKind.HEX_DIGIT_EXPECTED,
     MessageKind.UNMATCHED_TOKEN,
     MessageKind.UNTERMINATED_STRING,
 ]);