Add more mixin tests and start rejecting illegal syntax.

sdk/lib/_internal/compiler/implementation/scanner/parser.dart

Index: sdk/lib/_internal/compiler/implementation/scanner/parser.dart
diff --git a/sdk/lib/_internal/compiler/implementation/scanner/parser.dart b/sdk/lib/_internal/compiler/implementation/scanner/parser.dart
index 2909cc9e8bbe8c63146b326acdb644364fa526e3..91aa70be1edb080292ed7ddb825dbd7bfe44272c 100644
--- a/sdk/lib/_internal/compiler/implementation/scanner/parser.dart
+++ b/sdk/lib/_internal/compiler/implementation/scanner/parser.dart
@@ -266,7 +266,7 @@ class Parser {
       token = parseIdentifier(token.next);
       token = parseTypeVariablesOpt(token);
       token = expect('=', token);
-      token = parseMixinApplication(token);
+      token = parseMixinApplication(token, true);
       listener.endNamedMixinApplication(typedefKeyword, token);
     } else {
       listener.beginFunctionTypeAlias(token);
@@ -279,9 +279,13 @@ class Parser {
     return expect(';', token);
   }
 
-  Token parseMixinApplication(Token token) {
+  Token parseMixinApplication(Token token, bool isTypedef) {
     listener.beginMixinApplication(token);
-    token = parseModifiers(token);
+    if (isTypedef) {
+      token = parseModifiers(token);
+    } else {
+      listener.handleModifiers(0);

[ahe, 2013/01/21 12:38:53]

This is a hack. You should let endMixinApplication know that there are no
modifiers instead.

Also, I have generally tried to let the parser accept as much as possible, and
let later phases report errors. This gives better error recovery.

[kasperl, 2013/01/21 12:46:16]

Ah, okay. In that case, it's a hack used in at least one other part of the
parser not written by me and without any TODOs or indications that it's a hack.

[ahe, 2013/01/21 13:03:10]

Yes. I'm not sure I realized it the time, but it became painfully clear that
parseFunctionExpression is a hack when I looked at how to address
http://dartbug.com/6708.

parseFunctionBody and parseLiteralListOrMap do something similar, and it always
causes problems.

This call in parseLiteralListOrMap:

  listener.handleLiteralList(0, token, constKeyword, token);

causes problems for unparsing.

This call inparseFunctionBody:

  listener.endFunctionBody(0, null, token);

Means that the listener has to guess what to do based on weird argument
combinations:

  void endFunctionBody(int count, Token beginToken, Token endToken) {
    if (count == 0 && beginToken == null) {
      pushNode(new EmptyStatement(endToken));
    } else {
      pushNode(new Block(makeNodeList(count, beginToken, endToken, null)));
    }
  }

It seemed like a good idea at the time, but it wasn't :-(

[kasperl, 2013/01/21 13:04:46]

Yeah, that is pretty nasty. I'll try to address it by always allowing modifiers
and weed them out (report them) later during resolution.

+    }
     token = parseType(token);
     token = expect('with', token);
     token = parseTypeList(token);
@@ -485,8 +489,7 @@ class Parser {
     if (optional('extends', token)) {
       extendsKeyword = token;
       if (optional('with', token.next.next)) {
-        // TODO(kasperl): Disallow modifiers here.
-        token = parseMixinApplication(token.next);
+        token = parseMixinApplication(token.next, false);
       } else {
         token = parseType(token.next);
       }