x !== true && x !== false is simplified to false when x is not a boolean #9098

Found by a bug hunt over the 16 commits from eb087382 to cd641cbc.

If an untagged variant has both @as(true) and @as(false) cases, a match that doesn't name them loses its other checks:

@unboxed type t = D(Date.t) | @as(true) Lt | @as(false) Lf | R(RegExp.t)
let g = (v: t) => switch v { | D(_) => 2 | _ => 4 }

function g(v) {
  return 4;
}

g(new Date()) returns 4; it should return 2. At b123b7c3 the same program compiles to if (v instanceof Date) { return 2; } else { return 4; }, so this is a regression from the untagged dispatch rework (#9045, #9046, #9047).

A bool payload next to a single boolean literal is miscompiled on both revisions:

@unboxed type t = Bo(bool) | S(string) | @as(true) Lt
let f = (v: t) => switch v { | Bo(false) => 2 | _ => 6 }

function f(v) {
  if (v === true) {
    return 6;
  } else {
    return 2;
  }
}

f(S("hello")) returns 2; it should return 6.

A differential fuzzer generated 4,000 random untagged variants and matches, and compared the compiled code's results with a reference matcher. 17 results were wrong, and every one of them involves boolean literals as above.

Cause

Js_exp_make.simplify_and_ simplifies x === b1 && x === b2 and x !== b1 && x !== b2, where b1 and b2 are boolean constants, as if x were itself a boolean. That is how x !== true && x !== false becomes false. In an untagged variant x can be any of the payloads.

Related: #9035 fixed another rule in the same function that made the same assumption.

🤖 Generated with Claude Code