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

tests/compiler/dart2js/message_kind_helper.dart

 // Copyright (c) 2013, the Dart project authors.  Please see the AUTHORS file
 // for details. All rights reserved. Use of this source code is governed by a
 // BSD-style license that can be found in the LICENSE file.
 
 library dart2js.test.message_kind_helper;
 
 import 'package:expect/expect.dart';
 import 'dart:async';
 
 import '../../../sdk/lib/_internal/compiler/implementation/dart2jslib.dart' show
@@ skipping 22 matching lines @@
     MessageKind.FORMAL_DECLARED_STATIC,
     MessageKind.FUNCTION_TYPE_FORMAL_WITH_DEFAULT,
     MessageKind.HIDDEN_IMPLICIT_IMPORT,
     MessageKind.HIDDEN_IMPORT,
     MessageKind.INHERIT_GETTER_AND_METHOD,
     MessageKind.UNIMPLEMENTED_METHOD,
     MessageKind.UNIMPLEMENTED_METHOD_ONE,
     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
 /// here if a fatal error is unavoidable and leads to pending classes.
 /// Try to avoid adding exceptions here; a fatal error causes the compiler to
 /// stop before analyzing all input, and it isn't safe to reuse it.
 final Set<MessageKind> kindsWithPendingClasses = new Set<MessageKind>.from([
     // If you add something here, please file a *new* bug report.
 ]);
 
 /// Most messages can be tested without causing a fatal error. Add an exception
 /// here if a fatal error is unavoidable.
 /// Try to avoid adding exceptions here; a fatal error causes the compiler to
 /// 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,
 ]);
 
 Future<Compiler> check(MessageKind kind, Compiler cachedCompiler) {
   Expect.isNotNull(kind.howToFix);
   Expect.isFalse(kind.examples.isEmpty);
 
   return Future.forEach(kind.examples, (example) {
     if (example is String) {
@@ skipping 70 matching lines @@
       Expect.isTrue(!pendingStuff || kindsWithPendingClasses.contains(kind));
 
       if (!pendingStuff && !compiler.compilerWasCancelled) {
         // If there is pending stuff, or the compiler was cancelled, we
         // shouldn't reuse the compiler.
         cachedCompiler = compiler;
       }
     });
   }).then((_) => cachedCompiler);
 }