BoundaryML/baml · error

compilation failed: {e:?}

Error message

compilation failed: {e:?}

What it means

During `baml test`, the CLI compiled the project's program artifacts (via `compile_program_artifacts`, with optional bytecode cache and reuse plan) and the compiler returned an error. The CLI wraps it with `anyhow!("compilation failed: {e:?}")`, including the debug-formatted underlying compiler error, and aborts the test run — no tests execute until the project compiles.

Source

Thrown at baml_language/crates/baml_cli/src/test_command.rs:387

            if !errors.is_empty() {
                // Render the full diagnostic block so test errors look like
                // run/pack errors instead of a bullet list of messages. Sources
                // and paths cover every user file plus builtins — an error in one
                // file may carry related spans elsewhere.
                let rendered = crate::check_command::render_project_diagnostics(db, &errors);
                reporter.abandon();
                eprintln!("{rendered}");
                return Ok(crate::ExitCode::Other);
            }

            // 3. Compile + engine + runtime
            let compiled = crate::bytecode_cache::compile_program_artifacts(
                db,
                package,
                cache.as_ref(),
                reuse_plan.as_ref(),
            )
            .map_err(|e| anyhow!("compilation failed: {e:?}"))?;
            if let Some(ctx) = cache {
                let fresh = fresh_diagnostics
                    .as_ref()
                    .expect("a cache is present, so fresh diagnostics were computed");
                ctx.verify_and_store(
                    &session,
                    &compiled,
                    fresh,
                    reuse_plan.as_ref(),
                    stdlib_interface_hit,
                )?;
            }
            // Warm-run evidence: with the stdlib interface seeded this is 0 (the
            // seed served every stdlib package); a cold run reports up to 6.
            crate::bytecode_cache::cache_debug(format_args!(
                "stdlib interface: {} honest derivation(s) this process",
                baml_db::baml_compiler2_hir_ty::package_interface::stdlib_honest_derivations()
            ));

View on GitHub (pinned to bd85ce9dee)

Solutions

  1. Read the debug payload after "compilation failed:" — it names the file/span and the underlying compiler diagnostic; fix that error first.
  2. Run the compile/check step alone (e.g. `baml run --list` or an equivalent check command) to surface diagnostics faster.
  3. Revert or complete the recent edit that broke compilation.
  4. Regenerate any generated BAML sources and verify baml.toml is valid for this toolchain version.

Example fix

// before (my_func.baml)
function Foo() -> string { clients FooClient } // unresolved client
// after
function Foo() -> string { clients Gpt4 } // existing client
Defensive patterns

Strategy: validation

Validate before calling

// shell: fail fast before tests if sources don't compile
baml run --list > /dev/null 2> compile_err.log || { cat compile_err.log; exit 1; }

Try / catch

if ! baml test 2>err.log; then
  grep -q 'compilation failed' err.log && { echo "fix compiler errors first"; cat err.log; }
  exit 1
fi

Prevention

When it happens

Trigger: Any diagnostic error in the BAML sources under test (syntax error, type error, unresolved reference, invalid manifest/config) that makes `compile_program_artifacts` fail during `TestArgs::run`.

Common situations: A recent edit introduced a syntax or type error; a partially-merged refactor left broken sources; an incompatible baml.toml; running tests on a branch that doesn't compile; stale generated code referenced by sources.

Related errors


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