BoundaryML/baml · error

Encountered impossible type_expression declaration during pa

Error message

Encountered impossible type_expression declaration during parsing

What it means

A panic in parse_type_expression_block when the parsed declaration node is neither of the two expected type-expression declaration shapes (e.g. class-like vs enum-like sub_type). The final _ arm calls panic!("Encountered impossible type_expression declaration during parsing"), signaling the grammar produced a declaration variant the parser does not know — a grammar/parser desync bug.

Source

Thrown at engine/baml-lib/ast/src/parser/parse_type_expression_block.rs:169

                    FieldType::Symbol(FieldArity::Required, name.clone().unwrap(), None);
            }
        }
    }

    match name {
        Some(name) => TypeExpressionBlock {
            name,
            fields,
            methods,
            input,
            attributes,
            documentation: doc_comment.and_then(|c| parse_comment_block(c, diagnostics)),
            span: diagnostics.span(pair_span),
            sub_type: sub_type.0,
            type_span: diagnostics.span(sub_type.1),
            is_dynamic_type_def,
        },
        _ => panic!("Encountered impossible type_expression declaration during parsing"),
    }
}

#[cfg(test)]
mod tests {
    use internal_baml_diagnostics::{Diagnostics, SourceFile};
    use pest::{consumes_to, fails_with, parses_to, Parser};

    use super::*;
    use crate::parser::{BAMLParser, Rule};

    #[test]
    fn keyword_name_mandatory_whitespace() {
        // This is the expected form.
        parses_to! {
            parser: BAMLParser,
            input: "class Foo {}",
            rule: Rule::type_expression_block,

View on GitHub (pinned to bd85ce9dee)

Solutions

1. Check the declaration syntax at the reported span in your .bml file and use a supported block form (class/enum style)
2. Report the input to the BAML repo — the match needs a new arm for the unrecognized declaration rule
3. Pin a BAML version where the declaration grammar is fully covered by this parser
4. If extending the grammar, add the corresponding match arm in parse_type_expression_block

Example fix

// before
schemablock Foo { x: string }  // unsupported kind
// after
class Foo { x string }

// Only parse known declaration block kinds
const KNOWN: &[&str] = &["class", "enum", "type"];
fn known_blocks(src: &str) -> bool {
    src.lines().filter(|l| l.trim().contains(char::is_whitespace))
        .all(|l| KNOWN.iter().any(|k| l.trim_start().starts_with(k)))
}

fn is_supported_declaration(kind: &str) -> bool {
    matches!(kind, "class" | "enum" | "type")
}

std::panic::catch_unwind(|| parse_type_expression_block(pair, doc, sub_type, dynamic, &mut diagnostics))
    .map_err(|_| diagnostics.push("unknown type_expression declaration rule"));

When it happens

Trigger: parse_type_expression_block handling a type_expression pair whose inner rule does not match any of the destructured alternatives — typically after adding a new declaration kind to the grammar without extending this match.

Common situations: Seen when new BAML type declaration syntax (e.g. new schema block kinds) is added to the .pest grammar but parse_type_expression_block is not updated, or with hand-built parse trees in tests.

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

• Guaranteed by the grammar
• Encountered impossible class constructor during parsing
• Encountered impossible jinja expression during parsing
• Encountered impossible identifier during parsing.
• parse_named_args_list:, none for name of field/missing type

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