[internal] boogie exited with compilation errors: {}

Error message

[internal] boogie exited with compilation errors:
{}

What it means

When Boogie's output contains "errors detected in", Boogie found parsing, resolution, or type-checking errors in the generated Boogie program. Because the generated program is produced by the Move-to-Boogie translator, this is labeled [internal]: it indicates a translator/Boogie interface problem rather than a user verification failure. The raw Boogie output is included for diagnosis.

Source

Thrown at language/move-prover/boogie-backend/src/boogie_wrapper.rs:192

                }
            ));
        }
        if !output.status.success() {
            // Exit here with raw output.
            return Err(anyhow!(
                "Boogie error ({}): {}\n\nstderr:\n{}",
                output.status,
                out,
                err
            ));
        }
        if out.trim().starts_with("Unable to monomorphize") {
            return Err(anyhow!("Boogie error: {}\n\nstderr:\n{}", out, err));
        }
        // Boogie output contains the string "errors detected in" whenever parsing,
        // resolution, or type checking errors are discovered.
        if out.contains("errors detected in") {
            return Err(anyhow!(
                "[internal] boogie exited with compilation errors:\n{}",
                out
            ));
        }
        if out.contains("Prover error:") {
            return Err(anyhow!(
                "[internal] boogie exited with prover errors:\n{}",
                out
            ));
        }
        let mut errors = self.extract_verification_errors(&out);
        errors.extend(self.extract_inconclusive_errors(&out));
        errors.extend(self.extract_inconsistency_errors(&out));
        Ok(BoogieOutput {
            errors,
            all_output: out,
        })
    }

View on GitHub (pinned to fc4714a8ea)

Solutions

File/inspect issues against the move-to-boogie translator, since the .bpl input is generated — this is rarely a user code fix
Check the embedded Boogie output for the exact line/column of the resolution error
Confirm the installed Boogie version matches the expected one (versions are pinned in options.rs)
Re-run after `cargo clean` to rule out a stale translator binary mixing versions

Defensive patterns

Strategy: try-catch

Try / catch

match call_boogie(...) {
    Err(e) if e.to_string().contains("[internal] boogie exited with compilation errors") => {
        // This indicates a translator bug or version mismatch, not user code.
        eprintln!("{}", e); // embedded output names the failing .bpl line
        // report to move-prover maintainers
    }
    other => other,
}

Prevention

Keep translator (move-prover) and Boogie versions aligned
Avoid untested/edge-case Move constructs in verified code until supported
Regenerate .bpl fresh (cargo clean) to rule out stale translator output
Check existing move-prover issues for known translator bugs before debugging

When it happens

Trigger: call_boogie when out.contains("errors detected in") — i.e. the translated .bpl file failed Boogie's parse/resolution/type-check stage.

Common situations: Translator bugs on unusual Move constructs; Boogie version drift introducing new checks; corrupted .bpl temp files; verifying code generated by a different (older) move-prover translator.

Related errors

AI-assisted analysis of diem/diem@fc4714a8ea (2026-09-04). Data as JSON: /api/errors/4b966b9495a78658. Report an issue: GitHub.