BoundaryML/baml · error

Unexpected method call rule: {:?}

Error message

Unexpected method call rule: {:?}

What it means

This is a `unreachable!()` panic on the fallback arm of the postfix-operator match in `parse_expression`. The grammar only expects function application (`fn_app`), generic function application (`generic_fn_app`), and field access as postfix operators; when `map_postfix` receives any other operator rule, the grammar/code contract is broken and the parser panics. It is an internal invariant, not a user-facing syntax error.

Source

Thrown at engine/baml-lib/ast/src/parser/parse_expression.rs:127

                                unreachable!("expected function call when parsing method call")
                            }
                        },

                        Rule::generic_fn_app => match parse_generic_fn_app(inner, diagnostics)? {
                            Expression::App(fn_call) => Expression::MethodCall {
                                receiver: Box::new(left),
                                method: fn_call.name,
                                args: fn_call.args,
                                type_args: fn_call.type_args,
                                span: span.clone(),
                            },

                            _ => {
                                unreachable!("expected function call when parsing method call")
                            }
                        },

                        _ => unreachable!("Unexpected method call rule: {:?}", inner.as_rule()),
                    }
                }
                _ => unreachable!("Unexpected postfix operator: {:?}", operator.as_rule()),
            })
        })
        .map_infix(|left, operator, right| {
            let operator = match operator.as_rule() {
                Rule::EQ => BinaryOperator::Eq,
                Rule::NEQ => BinaryOperator::Neq,
                Rule::LT => BinaryOperator::Lt,
                Rule::LTEQ => BinaryOperator::LtEq,
                Rule::GT => BinaryOperator::Gt,
                Rule::GTEQ => BinaryOperator::GtEq,
                Rule::ADD => BinaryOperator::Add,
                Rule::SUB => BinaryOperator::Sub,
                Rule::MUL => BinaryOperator::Mul,
                Rule::DIV => BinaryOperator::Div,
                Rule::MOD => BinaryOperator::Mod,

View on GitHub (pinned to bd85ce9dee)

Solutions

1. Rewrite the BAML expression to use only supported postfix syntax: method calls `x.m()`, generic calls `x.m<T>()`, and field access `x.f`
2. If you added a new postfix rule to baml.pest, add a match arm in `map_postfix` in parse_expression.rs handling it (or emit diagnostics instead of panicking)
3. Upgrade/downgrade BAML so grammar and parser are from the same version

Example fix

// before (unsupported postfix syntax triggers panic)
let v = arr[0];
// after (use an API that supports indexing, or loop to access elements)
let v = first(arr);

// Restrict generated BAML postfix syntax to calls and field access:
function assertSupportedPostfix(expr) {
  if (/[\[\?\?]/.test(expr) && !/^\s*\w+\s*(\.|\()/.test(expr)) {
    throw new Error('Unsupported postfix syntax (indexing/optional chaining) panics the BAML parser: ' + expr);
  }
}

const usesOnlySupportedPostfix = (expr) => !/[\[\?]/.test(expr.replace(/\b\w+\(/g, ''));

catch (panicOutput) {
  if (String(panicOutput).includes('Unexpected postfix operator')) {
    logParserBug('grammar added a postfix op the parser cannot map', panicOutput);
    return null;
  }
  throw panicOutput;
}

When it happens

Trigger: The pratt parser's `map_postfix` receives an operator Pair whose rule is neither `fn_app`, `generic_fn_app`, nor the field-access rule — only possible after a .pest grammar change adding a new postfix operator (e.g. indexing `a[i]`, `?.`) that `parse_expression` does not yet map.

Common situations: Using a newly added postfix syntax in BAML against a parser that doesn't implement it; contributors adding index-access or optional-chaining rules to baml.pest without extending `map_postfix`.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

• Name should always be defined for attribute.
• Encountered impossible doc comment during parsing: {:?}, {:?
• c_for_init_stmt cannot accept empty input
• c_for_after_stmt cannot accept empty input
• block aware tail expression is not empty

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