BoundaryML/baml · critical

missing block address for jump target {target_block:?}; targ

Error message

missing block address for jump target {target_block:?}; target may have been skipped without redirect resolution

What it means

Panic in resolve_pending_target_pc when patching a pending jump to a MIR block: the emitter's block_addresses map has no recorded PC for the target block. This means the block was skipped during emission (e.g. removed as dead code) but no redirect to a fallback address was recorded, so the jump cannot be resolved. It is an internal emitter invariant: every jump target must either be emitted or redirected.

Source

Thrown at baml_language/crates/baml_compiler2_emit/src/emit.rs:2732

                    | Instruction::JumpIfNotNullOrPop(offset)
                        if *offset > 0 =>
                    {
                        *offset
                    }
                    _ => break,
                };
                target = target.wrapping_add_signed(next_offset);
            }
            self.patch_jump_to(source, target);
        }
    }

    /// Resolve a pending jump target to a concrete bytecode PC.
    fn resolve_pending_target_pc(&self, target: PendingJumpTarget) -> usize {
        match target {
            PendingJumpTarget::Block(target_block) => {
                *self.block_addresses.get(&target_block).unwrap_or_else(|| {
                    panic!(
                        "missing block address for jump target {target_block:?}; target may have been skipped without redirect resolution"
                    )
                })
            }
            PendingJumpTarget::Trap => self.trap_pc.unwrap_or_else(|| {
                panic!("missing trap PC for dead-unreachable jump target")
            }),
        }
    }

    /// Patch a specific jump to a specific destination.
    #[allow(clippy::cast_possible_wrap)]
    fn patch_jump_to(&mut self, instruction_idx: usize, destination: usize) {
        let offset = destination as isize - instruction_idx as isize;
        match self.bytecode.instructions[instruction_idx] {
            Instruction::Jump(_) => {
                self.bytecode.instructions[instruction_idx] = Instruction::Jump(offset);
            }

View on GitHub (pinned to bd85ce9dee)

Solutions

1. Ensure the optimization/emission pass records a redirect for skipped blocks so pending jump targets resolve to the surviving block.
2. Verify all MIR blocks reachable from jump instructions are emitted, or remap their targets before patching.
3. Reproduce with the offending BAML source and file a compiler bug with the MIR/CFG dump.
4. Pin to a compiler version without the regression while the bug is fixed.

// compiler panic — not user-catchable; wrap the build step
if !baml_cli_build_succeeds() {
    pin_previous_compiler_version();
}

When it happens

Trigger: Finalizing bytecode after emitting a function whose MIR control-flow graph contains a jump to a block that was never emitted and never had its pending target redirected (e.g. dead blocks elided without redirect resolution).

Common situations: Hit during BAML compiler development when an optimization pass drops unreachable or merged blocks but leaves jumps pointing at them; not reachable through normal user configuration.

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

• missing trap PC for dead-unreachable jump target
• expected jump instruction at index {instruction_idx}
• exception table: handler block {handler:?} has no PC address
• make_closure: lambda_idx {lambda_idx} out of range
• ntypeargs fits u16

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