Skip to main content

Crate brink_compiler

Crate brink_compiler 

Source
Expand description

Compiler for inkle’s ink narrative scripting language.

Orchestrates the full compilation pipeline: file discovery, parsing (brink-syntax), HIR lowering (brink-ir), semantic analysis (brink-analyzer), and codegen into the brink-format binary representation consumed by brink-runtime.

§The test-util-gated entry points (issue #2168)

brink_environment::compile(&Environment) (#1306) is the ruled determinism boundary and the sole production road into compilation — brink-cli and brink-web both go through it. This crate’s compile, compile_path, compile_with_options, and compile_path_with_options take a read_file closure (or read straight off disk) and bypass Environment entirely, so once stdlib source is mounted into the Environment manifest (#2080), anything reached through them will not see the stdlib — the story compiles and conventions silently do not classify.

Every call site of these four functions is test/bench/example code compiling an inline or fixture ink source with no need for a real Environment. They stay available for exactly that under the test-util feature (off by default). #[cfg(test)] cannot do this job — the callers span separate integration-test crates that cannot see this crate’s own #[cfg(test)]. A test/bench/example target that needs them opts in with a dev-dependencies edge enabling the feature, e.g.:

The guarantee this actually gives: an external crates.io consumer, or any isolated cargo check -p <crate> build that does not resolve brink-test-harness, cannot reach these functions without opting in. It is not a guarantee inside a --workspace build of this repo — brink-test-harness takes brink-compiler with features = ["test-util"] as a normal (non-dev) dependency, because its own [[bin]] targets and src/corpus.rs call these functions unconditionally, not just under a test cfg. Cargo’s feature unification then enables test-util for every crate sharing that brink-compiler instance across the whole workspace resolve, so a production fn added to e.g. brink-cli would still compile under cargo check --workspace. The CI job’s isolated -p brink-cli -p brink-web -p brink-lsp -p bevy-brink -p brink-environment check (added alongside this note) is what actually proves the fence for those crates, since it never resolves brink-test-harness.

[dev-dependencies]
brink-compiler = { workspace = true, features = ["test-util"] }

Structs§

AnalysisOptions
Tooling options for analysis: the registered host manifest and the severity policy for its external checks. Defaults to no manifest.
CompileOutput
Successful compilation output, including any non-fatal warnings.
FileId
Opaque identifier for a source file within a multi-file project.
ResolvedDiagnostic
A diagnostic resolved for consumption outside the compiler.

Enums§

CompileError
Errors that can occur during compilation.
DiagnosticCode
Stable error codes for brink diagnostics.
Dialect
Compiler dialect: gates T1b brink-extension syntax. Default StrictInk — divergence from the oracle-anchored ink subset is a visible, one-time, per-project choice (docs/t1b-surface-spec.md §1).
Severity
How seriously a diagnostic should be treated by a consumer (CLI renderer, LSP client, editor diagnostics panel).
TypePolicy
types project policy (docs/typed-mode-spec.md §1). Gradual is the pre-flip behavior — Unknown unifies with anything, annotations are optional seasoning, and the strict checks do not run. Strict requires dialect = brink.