fasta: excessive errors with missing sync*

[rakudrama]

class CC<TT> {
  Iterable<Map<TT, MM>> foo<MM>() sync* {
    yield null;
    yield <TT, MM>{};
  }
}

main() {
  dynamic c = new CC<String>();
  print(c.foo<int>());
}

If you leave out the sync* you get eleven errors

$ dart2js --strong bug1a5s.dart
bug1a5s.dart:3:11:
Error: Expected ';' before this.

bug1a5s.dart:3:5:
Error: Getter not found: 'yield'.

bug1a5s.dart:4:5:
Error: Getter not found: 'yield'.

bug1a5s.dart:4:14:
Error: Expected ';' before this.

bug1a5s.dart:4:14:
Error: Expected an identifier, but got ','.

bug1a5s.dart:4:14:
Error: Getter not found: ''.

bug1a5s.dart:4:14:
Error: Unexpected token ';'.

bug1a5s.dart:3:5:
Error: The getter 'yield' isn't defined for the class '#lib1::CC<#lib1::CC::TT>'.

bug1a5s.dart:4:5:
Error: The getter 'yield' isn't defined for the class '#lib1::CC<#lib1::CC::TT>'.

bug1a5s.dart:4:14:
Error: The getter '' isn't defined for the class '#lib1::CC<#lib1::CC::TT>'.

bug1a5s.dart:4:18:
Error: The method '>' isn't defined for the class 'dart.core::Type'.

Error: Compilation failed.
$ 

[bwilkerson]

Today there are 8 diagnostics displayed by analyzer. That's still too high.

If we find a yield statement in a non-generator function we should flag that as an error but then proceed to parse a yield statement. There should be a second diagnostic for the second yield statement, but then it should also be parsed as a normal yield statement. Ideally, there wouldn't be any other diagnostics.

[lrhn]

An issue is that yield (and await) are not reserved words in non-async/async*/sync* functions, so "find a yield statement" won't be trivial.

void main() {
  yield (2 + 5); // Valid yield statement, valid plain expression.
  await (Future.value(42));
}

void await(Future<Object?> f) {
  f.then(print);
}

void yield(Object? v) {
  print(v);
}

This code is valid, so seeing yield is not by itself an issue. If there is an error (say yield x; is an error because x isn't allowed after an identifier) and it looks like someone intended a yield-statement, then recovery can try to make it a yield statement. If there is no error, we shouldn't introduce one.

[bwilkerson]

... recovery can try to make it a yield statement. If there is no error, we shouldn't introduce one.

Exactly what I tried to say. Sorry I wasn't more clear.