Skip to main content

validate_generated_code

Function validate_generated_code 

Source
pub fn validate_generated_code(
    code: &str,
    backend_name: &str,
) -> ValidationOutcome
Expand description

Validate one backend’s generated output with the real compilers and linters for its target language, collapsed to the three outcomes a caller needs to decide what to print and whether to fail a build.

This is validate_with_tools built on top of, not reimplemented: the pass/fail split follows the same non-strict policy as ToolValidation::into_result outside STRICT_ENV_VAR – a tool that is not installed is tolerated, never a build failure. Keeping the collapse here, delegating to ToolValidation::into_result_with_strictness rather than re-deriving “missing is fine, a real finding is not” a second time, is what keeps that policy defined in exactly one place; see the doc comment on ToolValidation::into_result_with_strictness for why ValidationOutcome::Unsupported is exempt from strictness entirely rather than becoming a fourth, stricter failure case.

§This shells out to real external tools

poly, tsc, node, gofmt, javac, kotlinc, elixirc, ruby, and others, depending on backend_name – see validate_with_tools’s match arms. When a tool is not installed, probing for it (Command::new(tool).arg(probe_arg).output()) fails fast: the OS reports “no such file” as soon as it tries to spawn the process, so an absent tool costs microseconds and never blocks. The cost that matters is the opposite case – a tool that is installed. javac and kotlinc each pay JVM startup (commonly over a second) on top of a real compile; tsc --checkJs --strict runs a full TypeScript typecheck. A caller that invokes this unconditionally on every scythe generate would make every run pay that cost for every backend the file targets, on any machine that happens to have the tool installed – and would silently validate less on a machine that doesn’t, with no way for the user to tell which happened short of reading ValidationOutcome::Passed’s tools_run/ tools_missing fields. Callers should gate this behind an explicit opt-in (e.g. a --verify flag), not run it unconditionally on every generate.