Prior to commit 8f09626, type arguments to an operator request were treated as an error.
Currently, they are parsed correctly, but they are not stored in the AST, and are not passed to the method at runtime. This needs to be fixed.
Because of the way that precedence is handled in the parser, there can be a long interval between reading the type arguments and creating the opNode that ought to store them. The parser should probably get its own operator objects, since these could also implement the precedence rules; right now; the parser represents operators as characters, not operator objects.
Prior to commit 8f09626, type arguments to an operator request were treated as an error. Currently, they are parsed correctly, but they are not stored in the AST, and are not passed to the method at runtime. This needs to be fixed.
js/tests/known-failing/t061_operatorWithTypeArg_test.grace tests for this case.
Because of the way that precedence is handled in the parser, there can be a long interval between reading the type arguments and creating the
opNodethat ought to store them. The parser should probably get its own operator objects, since these could also implement the precedence rules; right now; the parser represents operators as characters, not operator objects.