6016b08712
lowerBinaryOp derived the result type from the LHS alone and emitted add/sub/mul/div/mod without checking the RHS, so `s64 + string` lowered as `add : s64` and reinterpreted the string's bytes — printing garbage instead of erroring. Add isArithOperand (int / float / vector / pointer, plus custom int widths) and, for `+ - * / %`, diagnose `cannot apply '<op>' to operands of type '<lhs>' and '<rhs>'` and return a placeholder sentinel instead of the corrupting op. `.unresolved` operands pass through so a type we couldn't infer is never falsely rejected; the existing optional-unwrap and int×float promotion are accounted for before the check. Ordering (`< <= > >=`) and bitwise/shift (`& | ^ << >>`) ops share the same LHS-derived-type hole and are left as a noted follow-up in the issue. Regression: examples/214-arith-operand-type-check.sx (s64 + string, and non-numeric LHS string * s64).
2 lines
2 B
Plaintext
2 lines
2 B
Plaintext
1
|