Sibling articles under this feature previously restated requirements in inconsistent forms.
mod host bridge - Design model
Platform spec article
mod host bridge - Design model
Spec standingStandard
-
This feature hub owns normative MUST/SHOULD contract text for Mod host bridge.
Context
Decision
This feature hub owns normative MUST/SHOULD contract text. Sibling articles must not redefine hub requirements and should link here for authority.
Consequences
Contract changes start on the hub or in linked ADRs, then propagate to articles and implementation anchors.
Verification anchors
site/website/src/content/docs/platform-spec/compiler/compiler-mods/mod-host-bridge/index.mdxarticle bundle under the same feature directory.
-
Platform-spec text supersedes informal crate comments for Mod host bridge.
Context
Implementation crates accumulated informal notes that diverged from published contracts.
Decision
Normative platform-spec prose and ADRs under this feature supersede informal comments in implementation crates until explicitly migrated into spec text.
Consequences
Engineers file spec/ADR updates when behavior changes; crate comments are non-authoritative for conformance arguments.
Verification anchors
compiler/crates/beskid_analysis/compiler/crates/beskid_codegen/compiler/crates/beskid_analysis/src/services.rs
-
Mods previously risked manifest attach lists for discovery.
Context
Modpackages must export public Beskid types implementing SDK contracts; host loads AOT artifacts andmod.descriptor.jsonregistrations—not manifest attach metadata.Decision
Contract discovery uses
(contractId, typeId, entrySymbol)tuples; failures emit E1821–E1870 beforemod.collect.Consequences
JIT mod execution is not normative; rebuild uses
beskid mod rebuild.Verification anchors
compiler/crates/beskid_analysis/mod artifact store paths in analysis services.
- Mod host bridge - AOT artifact contract On-disk mod artifact layout, cache keys, export descriptor schema, and load-failure diagnostics.
- mod host bridge - Contracts and edge cases Reference compiler-owned execution, capability policy, and communication with compile-time Beskid modules.
- mod host bridge - Design model Rust-side mod host execution, AOT artifact lifecycle, capability policy, and typed merge.
- mod host bridge - Examples Reference compiler-owned execution, capability policy, and communication with compile-time Beskid modules.
- mod host bridge - FAQ and troubleshooting Reference compiler-owned execution, capability policy, and communication with compile-time Beskid modules.
- mod host bridge - Flow and algorithm Reference compiler-owned execution, capability policy, and communication with compile-time Beskid modules.
- mod host bridge - Verification and traceability Reference compiler-owned execution, capability policy, and communication with compile-time Beskid modules.
0 revisions (git unavailable at build; counts may be empty)
No commits recorded for this path.
Compile-time mod execution flow
Reference ordering from parse through mod collection, generation, semantic analysis, rewrite, and lowering.
Full tree: run pnpm verify:platform-spec-layout (writes src/generated/platform-spec-layout-report.json).
This article documents the design model for the Mod host bridge.
Language alignment
Section titled “Language alignment”Executes Collector → Generator → semantic gate → Analyzer → Rewriter for Mod packages discovered from the dependency graph. Scope narrowing is owned by Collector contracts, not manifest attach fields.
Persistent entities
Section titled “Persistent entities”- Compilation instance — active host compilation under transformation.
- Mod artifact — AOT-compiled output for a
Modpackage, cached under object/package store paths. - Syntax snapshot — immutable tree with stable node identities for incremental keys.
- Capability tokens — host-granted permissions for diagnostics, typed emit, rewrite, and optional source/semantic reads.
Boundaries
Section titled “Boundaries”- Mod SDK facades never bypass the host bridge for effects.
- Compiler composition / IoC remains Rust-owned (Pipeline composition).
- Mod execution is AOT-only; no compile-time JIT path is normative.
Mod artifact lifecycle
Section titled “Mod artifact lifecycle”- Discovery — Resolve all transitive
type: Moddependencies from hostCompilePlan. - Build — On first detection or hash change, compile mod package AOT and store artifact.
- Registry fetch — Package manager fetched mods: build once, cache artifact by lock hash + target triple.
- Workspace edit — Local
Modprojects rebuild on source/config hash change (eager incremental check). - Load — Host loads artifacts before
mod.collectfor the active compilation.
CLI commands beskid mod rebuild (clean + build mod artifacts) and beskid mod clean manage object-store mod outputs.
Contract discovery
Section titled “Contract discovery”Mod packages must export contract implementations as public Beskid types implementing SDK contract interfaces. The host must not rely on manifest attach lists or language-level meta items for registration.
At mod.load, for each resolved Mod package the host:
- Opens the AOT artifact for the active target triple (AOT artifact contract).
- Parses
mod.descriptor.json(authoritative when present) and validates the embeddedregistrationsarray. - Schedules one host entry per
(contractId, typeId, entrySymbol)tuple.
| Field | Role |
|---|---|
contractId | Stable SDK contract identity (Beskid.Compiler.Collect.Collector, etc.). |
typeId | Public type in the mod assembly implementing the contract. |
entrySymbol | Native export used to invoke the contract at the mod boundary. |
Conflicting registrations or bootstrap failures must emit E1821–E1835 / E1851–E1870 and abort scheduling before mod.collect. Scope narrowing remains in Collector implementations, not manifest metadata.
Capability matrix (normative vocabulary)
Section titled “Capability matrix (normative vocabulary)”Manifest project.mod.capabilities lists entries from this closed set. Defaults when omitted: diagnostics only.
| Capability | Grants |
|---|---|
diagnostics | Emit compiler-native diagnostics. |
read_project_sources | Read UTF-8 from resolved module roots of the host compilation. |
emit_syntax | Apply typed AST contributions from Generator. |
query_semantic_snapshot | Read semantic snapshot after the diagnostics gate. |
rewrite_syntax | Apply typed Rewriter replacements. |
extern_ffi | Opt-in FFI bridge per FFI and extern. |
Pipeline observation
Section titled “Pipeline observation”Host boundaries must emit beskid_pipeline phase ids: mod.load, mod.collect, mod.generate, syntax.generation, semantic.snapshot, mod.analyze, mod.rewrite, lower.ready. See Compiler Mods / phase ids.
Anchored code paths
Section titled “Anchored code paths”compiler/crates/beskid_analysis/src/mod_host/— collection, typed merge, contract dispatch, analyzer / rewrite orchestration.compiler/crates/beskid_analysis/src/mod_host/invoker.rs—ContractInvokertrait + Stub / Scripted invokers used by host pipeline and tests.compiler/crates/beskid_analysis/src/mod_host/validate.rs— pre-mod.collectregistration validation pass that emits E1828, E1829, E1851, E1852, E1853, E1854, E1855.compiler/crates/beskid_analysis/src/mod_host/diagnostics.rs— structuredModHostIssue/ModHostDiagnosticscarriers.compiler/crates/beskid_analysis/src/services/front_end.rs— front-end session hook forrun_through_generate/run_analyze_rewrite.compiler/crates/beskid_pipeline/— phase ids and observers.compiler/crates/beskid_codegen/src/services.rs— lowering after consistent merged program.