[cfe] Parsing `e<T1> is T2`

[eernstg]

Cf. https://github.com/dart-lang/co19/blob/aff1a334d7875e465c2f43e1b38774512fbb4ba4/LanguageFeatures/Constructor-tear-offs/named_constructor_A02_t02.dart, the CFE parser reports several errors when it encounters an explicit tearoff followed by is:

tests/co19/src/LanguageFeatures/Constructor-tear-offs/named_constructor_A02_t02.dart:27:31: Error: A comparison expression can't be an operand of another comparison expression.
Try putting parentheses around one of the comparisons.
  Expect.isTrue((C.constr)<int> is C Function<T extends int>(T));
                              ^
tests/co19/src/LanguageFeatures/Constructor-tear-offs/named_constructor_A02_t02.dart:27:33: Error: Expected an identifier, but got 'is'.
Try inserting an identifier before 'is'.
  Expect.isTrue((C.constr)<int> is C Function<T extends int>(T));
                                ^^
tests/co19/src/LanguageFeatures/Constructor-tear-offs/named_constructor_A02_t02.dart:27:27: Error: The operator '<' isn't defined for the class 'C<T> Function<T>(T)'.
 - 'C' is from 'tests/co19/src/LanguageFeatures/Constructor-tear-offs/named_constructor_A02_t02.dart'.
Try correcting the operator to an existing operator, or defining a '<' operator.
  Expect.isTrue((C.constr)<int> is C Function<T extends int>(T));
                          ^

However, I believe that there is no way a syntactically correct program could have the token > followed by is unless that > is the end of a <typeArguments> term, and I believe this implies that is can be treated like the disambiguation tokens (( ) ] } : ; , . ? == != .. ?. ?? ?.. & | ^ + * % / ~/), such that the constructs in this test will parse successfully, even though the construct with is isn't ambiguous. So when we see is, we decide that (C.constr)<int> is derived from <primary><selector>.

[johnniwinther]

@stereotype441 Could you take a look at this?

[eernstg]

A similar situation arises in co19/LanguageFeatures/Constructor-tear-offs/unnamed_constructor_A05_t02.

[stereotype441]

Sure, adding is to the list of tokens that cause < to be treated as starting a list of type arguments should be straightforward, and I'm glad to do it. I think we should add as too. I can also take responsibility for updating the feature specification.

@lrhn does this sound reasonable to you?

[lrhn]

Since is is a reserved word, I think it should be safe to make it a stop-word for >.

I'd prefer if we could also make as one, but that is very hypothetically breaking since it's not a reserved word, making the following valid Dart:

class C {
  int get as => 42;
  void test() {
    var x = g(f<int, int> as);
    print(x);
  }
}
void main() {
  C().test(); // Prints "37 - 87"
}
g(a, [b = "absent"]) => "$a - $b";
f<S, T>() {}
extension on Function {
  operator <(_) => 37;
}
extension on Type {
  operator >(_) => 87;
}

If anyone actually writes that code, I'd be happy to see it start failing, so maybe we should also use as as a delimitwr token.

[stereotype441]

@lrhn Sounds good to me. I'll work on a fix.