Handle multi-character binary operators split by SWC's lexer

The SWC lexer can tokenize multi-character binary operators as separate
tokens when the operator follows a TypeScript type position. For
example, in `0 as number <= 1`, after parsing the type `number` the
lexer doesn't merge `<` with the trailing `=` and emits them as two
tokens — even though the parser's expression layer correctly treats
the whole thing as a single `<=` BinExpr.

`get_flattened_bin_expr` searched for a single token whose text equals
the binary operator (`<=`), found none, and panicked on the `unwrap()`:

    thread 'main' panicked at flatten_binary_expr.rs:25:
    called `Option::unwrap()` on a `None` value

This affected at least `<=` and `>=` after `as`-expressions; the
existing `<<` test in BinaryExpression_All hints the lexer has split
multi-char operators in the past too.

Move the operator-token lookup into a small helper and, when the full
operator-text match fails, fall back to matching just the operator's
first character. The fallback is sufficient because callers only need
the token's start position (e.g. `start_line_fast` for operator
position decisions); for the split case, the leading `<` token
carries the same start position as the conceptual `<=` operator.

Refs denoland/deno#31988.

Author: fibibot

src/generation/swc/flatten_binary_expr.rs

@@ -22,7 +22,7 @@ pub struct BinExprOp<'a> {
 pub fn get_flattened_bin_expr<'a, 'b>(node: &'b BinExpr<'a>, context: &mut Context<'a>) -> Vec<BinExprItem<'a>> {
   let mut items = Vec::new();
   let operator_token = BinExprOp {
-    token: context.token_finder.get_first_operator_after(&node.left, node.op().as_str()).unwrap(),
+    token: find_operator_token_after(&node.left, node.op(), context),
     op: node.op(),
   };
   let is_op_same_line = get_operator_position(node, operator_token.token, context) == OperatorPosition::SameLine;
@@ -68,6 +68,29 @@ pub fn get_flattened_bin_expr<'a, 'b>(node: &'b BinExpr<'a>, context: &mut Conte
 
   return items;
 
+  /// Locate the binary operator's leading token, immediately after the left
+  /// operand. Most of the time this is just `get_first_operator_after` with
+  /// the operator's full text (e.g. `<=`), but the SWC lexer can split
+  /// multi-character operators into separate tokens when the operator
+  /// follows a TypeScript type position. For example `0 as number <= 1`
+  /// tokenizes `<=` as `<` then `=`. In that case we fall back to matching
+  /// just the operator's first character (`<`), which is always a single
+  /// token whose start position is what callers actually need (e.g. for
+  /// `start_line_fast`).
+  fn find_operator_token_after<'a>(left: &impl SourceRanged, op: BinaryOp, context: &mut Context<'a>) -> &'a TokenAndSpan {
+    let op_text = op.as_str();
+    if let Some(tok) = context.token_finder.get_first_operator_after(left, op_text) {
+      return tok;
+    }
+    if op_text.len() > 1 {
+      let first_char_text = &op_text[..1];
+      if let Some(tok) = context.token_finder.get_first_operator_after(left, first_char_text) {
+        return tok;
+      }
+    }
+    panic!("could not locate operator token for binary op `{op_text}`");
+  }
+
   fn is_expression_breakable(top_op: BinaryOp, op: BinaryOp) -> bool {
     if top_op.is_add_sub() {
       op.is_add_sub()

tests/specs/expressions/BinaryExpression/BinaryExpression_All.txt

@@ -286,3 +286,15 @@ const test =
 const test =
     // testing
     a + b + c;
+
+== should format multi-character comparison after a TS as-expression (LtEq) ==
+0 as number <= 1;
+
+[expect]
+0 as number <= 1;
+
+== should format multi-character comparison after a TS as-expression (GtEq) ==
+0 as number >= 1;
+
+[expect]
+0 as number >= 1;