CI and VSIX builds enable different beskid_runtime features. Confusing feature gates with ABI bumps breaks compatibility checks.
Runtime feature flags
Platform spec feature
Runtime feature flags
Spec standingStandard
-
Optional runtime capabilities toggle code paths without bumping BESKID_RUNTIME_ABI_VERSION.
Context
Decision
Concept Rule BESKID_RUNTIME_ABI_VERSIONChanges only on breaking layout/signature per D-EXEC-ABI-0002 Cargo featuresmetrics,arrays_backing,sched— build-time togglesAdditive exports New feature-gated symbols may ship without ABI bump if old artifacts never import them Shipped binaries Must document enabled features in release notes Tests Compiler tests enable features explicitly when validating optional paths Consequences
Mismatch (test expects
arrays_backing, default runtime does not) fails logically without ABI version inequality.Verification anchors
beskid_runtime/Cargo.toml; design model feature table. -
Without the feature, array_new may emit header-only arrays with null backing.
Context
Array lowering depends on whether the linked runtime allocates element storage behind
BeskidArrayheaders.Decision
arrays_backingBehavior Enabled array_newallocates element storage;ptrnon-null when length > 0Disabled Header-only arrays; ptrmay be nullABI Symbol list unchanged; semantics differ by build — document in release matrices Alignment Shipped CLI/VSIX should enable arrays_backingfor reference user workflowsConsequences
Conformance and doc tests must pin feature set when asserting array behavior.
Verification anchors
beskid_runtimearray_new; runtime JIT tests with feature flags.
- Contracts and edge cases MUST/SHOULD rules for optional runtime features and toolchain alignment.
- Design model Cargo feature gates, runtime build capabilities, and compiler alignment expectations.
- Examples Building runtime with features, array backing expectations, and engine extern_dlopen.
- FAQ and troubleshooting Optional runtime features vs ABI version, array backing surprises, and CI alignment.
- Flow and algorithm Selecting runtime features at build time and validating behavior at run time.
- Verification and traceability Cargo feature definitions, conditional compilation gates, and CI matrix expectations.
0 revisions (git unavailable at build; counts may be empty)
No commits recorded for this path.
| Section id | Required | Found |
|---|---|---|
what-this-feature-specifies | yes | yes |
implementation-anchors | yes | yes |
Full tree: run pnpm verify:platform-spec-layout (writes src/generated/platform-spec-layout-report.json).
What this feature specifies
Runtime feature flags defines one operational contract that a newcomer can follow end-to-end: first the model, then execution flow, then strict guarantees, concrete examples, and verification guidance.
Implementation anchors
- Runtime compile-time flags and exports in
compiler/crates/beskid_runtime/src/lib.rs - Runtime builtins feature gating in
compiler/crates/beskid_runtime/src/builtins/mod.rs - Execution setup in
compiler/crates/beskid_cli/src/commands/doc.rs - Runtime tests in
compiler/crates/beskid_tests/src/runtime/jit.rs
Decisions
Section titled “Decisions”No open decisions. Closed choices are normative ADRs under adr/ (D-EXEC-RT-0014, D-EXEC-RT-0015); use the reader ADRs tab for expandable detail.
Articles
- Cargo features are separate from ABI versionOptional runtime capabilities toggle code paths without bumping BESKID_RUNTIME_ABI_VERSION.
- Contracts and edge casesMUST/SHOULD rules for optional runtime features and toolchain alignment.
- Design modelCargo feature gates, runtime build capabilities, and compiler alignment expectations.
- ExamplesBuilding runtime with features, array backing expectations, and engine extern_dlopen.
- FAQ and troubleshootingOptional runtime features vs ABI version, array backing surprises, and CI alignment.
- Flow and algorithmSelecting runtime features at build time and validating behavior at run time.
- Verification and traceabilityCargo feature definitions, conditional compilation gates, and CI matrix expectations.