Sibling articles under this feature previously restated requirements in inconsistent forms.
mod host bridge - Examples
Platform spec article
mod host bridge - Examples
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 collects examples for mod host bridge (informative sketches aligned with contracts).
Example A — Minimal query
Section titled “Example A — Minimal query”A compile-time module reads a syntax attribute using the query API, then emits a diagnostic without mutating syntax.
Example B — Emitter sketch
Section titled “Example B — Emitter sketch”A contributor constructs a new method declaration through Beskid.Compiler.Emit, attaches trivia, and registers it with the incremental graph.
Executable snippets will track the reference implementation as mod host execution lands in the compiler; until then, treat these as specification fixtures.