BoundaryML/baml · error

negative shift amount in >>= operator

Error message

negative shift amount in >>= operator

What it means

This error is raised by the THIR interpreter while executing a `>>=` compound-assignment statement in a BAML function. After both operands have already been confirmed to be integers, the evaluator checks the right-hand shift amount `b` and aborts with `bail!` when it is negative, because Rust's `>>` on i64 panics (or overflows in debug) for negative shift counts, so the interpreter surfaces a controlled diagnostic instead of crashing the VM. The input at fault is the RHS expression of the `x >>= n` statement: it evaluated to an integer less than zero — typically the result of an arithmetic expression such as `x >>= a - b` where `a < b`. Fix by clamping or validating the shift amount (e.g. `if n < 0 { 0 } else { n }`) before the assignment.

Source

Thrown at engine/baml-compiler/src/thir/interpret.rs:1002

                            AssignOp::BitOrAssign => match (current_val.clone(), rhs_val.clone()) {
                                (BamlValueWithMeta::Int(a, meta), BamlValueWithMeta::Int(b, _)) => {
                                    BamlValueWithMeta::Int(a | b, meta)
                                }
                                _ => bail!("bitwise |= requires integer operands"),
                            },
                            AssignOp::ShlAssign => match (current_val.clone(), rhs_val.clone()) {
                                (BamlValueWithMeta::Int(a, meta), BamlValueWithMeta::Int(b, _)) => {
                                    if b < 0 {
                                        bail!("negative shift amount in <<= operator");
                                    }
                                    BamlValueWithMeta::Int(a << b, meta)
                                }
                                _ => bail!("shift <<= requires integer operands"),
                            },
                            AssignOp::ShrAssign => match (current_val.clone(), rhs_val.clone()) {
                                (BamlValueWithMeta::Int(a, meta), BamlValueWithMeta::Int(b, _)) => {
                                    if b < 0 {
                                        bail!("negative shift amount in >>= operator");
                                    }
                                    BamlValueWithMeta::Int(a >> b, meta)
                                }
                                _ => bail!("shift >>= requires integer operands"),
                            },
                        };

                        // Assign the result back to the target expression
                        assign_to_expr(
                            left,
                            result_val,
                            scopes,
                            thir,
                            run_llm_function,
                            watch_handler,
                            function_name,
                        )
                        .await?;

View on GitHub (pinned to bd85ce9dee)

Solutions

1. Clamp the shift amount: `let s = if d < 0 { 0 } else { d };` before `x >>= s;`.
2. If negative means a left shift, branch to `<<=` for that case.
3. Validate inputs that determine the shift amount.

Example fix

// before (BAML)
x >>= j - i; // error if j < i: negative shift amount in >>= operator

// after
let amt = if j > i { j - i } else { 0 };
x >>= amt;

// clamp the right-shift amount before executing >>=
if (!Number.isInteger(sh) || sh < 0) sh = 0;
const clampShr = (n: number): number => (Number.isInteger(n) && n >= 0 ? n : 0);

const validShiftAmount = (v: unknown): v is number => typeof v === "number" && Number.isInteger(v) && v >= 0;

try {
  await runBaml(program);
} catch (e) {
  if (String(e).includes("negative shift amount in >>= operator")) {
    // clamp to 0 or route negative cases to <<= and retry
  } else { throw e; }
}

When it happens

Trigger: Executing `x >>= y` where `y` is an Int < 0 at runtime, e.g. `x >>= -1` or a computed expression like `x >>= k - j` that can go negative.

Common situations: Dynamic shift amounts from subtraction or external input that was assumed non-negative; mirrored left-shift code where the sign flipped.

Understand the failure class

Background: "value must be between 0 and 1" / "out of range" / "must not be negative" errors: fixing range-validation failures across open-source libraries — this error's family across 42 libraries.

Related errors

• negative shift amount in <<= operator
• shift <<= requires integer operands
• shift >>= requires integer operands
• bitwise ^= requires integer operands
• bitwise &= requires integer operands

AI-assisted analysis of BoundaryML/baml@bd85ce9dee (2026-09-12). Data as JSON: /api/errors/18924b0b661eac82. Report an issue: GitHub.