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§
- Analysis
Options - Tooling options for analysis: the registered host manifest and the severity policy for its external checks. Defaults to no manifest.
- Compile
Output - Successful compilation output, including any non-fatal warnings.
- FileId
- Opaque identifier for a source file within a multi-file project.
- Resolved
Diagnostic - A diagnostic resolved for consumption outside the compiler.
Enums§
- Compile
Error - Errors that can occur during compilation.
- Diagnostic
Code - 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).
- Type
Policy typesproject policy (docs/typed-mode-spec.md §1).Gradualis the pre-flip behavior —Unknownunifies with anything, annotations are optional seasoning, and the strict checks do not run.Strictrequiresdialect = brink.