Skip to main content

CodeGenerator

Trait CodeGenerator 

Source
pub trait CodeGenerator {
    // Required methods
    fn target(&self) -> &TargetProfile;
    fn generate_module(
        &self,
        module: &AIRModule,
    ) -> Result<GeneratedCode, CodegenError>;
    fn generate_project(
        &self,
        modules: &[(&AIRModule, &Path)],
    ) -> Result<GeneratedCode, CodegenError>;

    // Provided methods
    fn needs_ai_synthesis(&self, node: &AIRNode) -> bool { ... }
    fn entry_invocation(&self, main_is_async: bool) -> Option<String> { ... }
    fn generate_tests(
        &self,
        modules: &[(&AIRModule, &Path)],
        framework: &str,
    ) -> Result<TestArtifacts, CodegenError> { ... }
}
Expand description

The trait all per-target code generators implement.

Each target (JS, TS, Python, Rust, Go) provides a struct that implements this trait. The generate_module method transforms a fully-lowered AIR module into target-specific source code.

Required Methods§

Source

fn target(&self) -> &TargetProfile

Returns the target profile for this generator.

Source

fn generate_module( &self, module: &AIRModule, ) -> Result<GeneratedCode, CodegenError>

Generates target code from a fully-lowered AIR module.

§Errors

Returns CodegenError if the module contains constructs that cannot be represented in the target language.

Source

fn generate_project( &self, modules: &[(&AIRModule, &Path)], ) -> Result<GeneratedCode, CodegenError>

Generates target code from multiple AIR modules with their source paths.

Per spec §20.6.1 (DQ19 resolved), each reached module is emitted to its own target file and cross-module references are wired with the target’s native import mechanism (ESM import, Python package imports, Rust mod/use, Go package files). Every v1 backend (JS, TS, Python, Rust, Go) overrides this with its per-module native-import emitter, so this is a required method — there is no default. (The single-module Self::generate_module is the self-contained, runtime-inlining emit used by per-backend unit tests, not a multi-module fallback.)

Provided Methods§

Source

fn needs_ai_synthesis(&self, node: &AIRNode) -> bool

Returns true when the given AIR node should go through Tier 1 AI synthesis (§17.2, Q3 amended).

The default implementation consults TargetProfile::ai_hints via crate::ai_synthesis::needs_ai_synthesis. Backends that want per-node overrides (e.g., only non-trivial match expressions) can override this method.

Source

fn entry_invocation(&self, main_is_async: bool) -> Option<String>

Returns the source-code snippet that invokes the user’s main function as the entry point for this target, or None if the target has a native entry-point convention (Rust fn main, Go func main) that runs without a synthetic call.

main_is_async is true when the user’s main function is declared async fn; targets with native async runtimes (JS, TS, Python) wrap the call in an event-loop driver in that case.

Targets that need a trailing invocation (JS, TS, Python) override this to return e.g. "main();\n". The default generate_project appends the snippet when any module declares a top-level main function.

Source

fn generate_tests( &self, modules: &[(&AIRModule, &Path)], framework: &str, ) -> Result<TestArtifacts, CodegenError>

Transpile the project’s @test functions into the target’s idiomatic test framework (project mode, §20.6.2).

framework selects the deep-config test-framework variant ("vitest" / "jest" for js/ts; "pytest" / "unittest" for python; ignored for rust/go, whose frameworks are universal — cargo test / go test). Returns the test files to write into the scaffolded project plus an optional snippet to append to the entry file (Rust wires its inline #[cfg(test)] mod from src/main.rs). When the project has no @test functions the returned TestArtifacts is empty.

The default implementation returns no test artifacts; every v1 backend overrides it.

§Errors

Returns CodegenError if a test body contains a construct that cannot be represented in the target language.

Dyn Compatibility§

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors§