CI and VSIX builds enable different beskid_runtime features. Confusing feature gates with ABI bumps breaks compatibility checks.
Examples
Platform spec article
Examples
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).
Enable array backing for tests
Section titled “Enable array backing for tests”cargo test -p beskid_tests --features beskid_runtime/arrays_backing(Exact feature propagation follows workspace Cargo.toml dependency declarations—maintainers mirror the pattern used in compiler CI.)
Header-only array scenario (default)
Section titled “Header-only array scenario (default)”A lowered test creates array_new(8, 100) without arrays_backing. Inspection shows non-zero len but ptr == null. Tests that dereference elements must enable backing or avoid element access.
Metrics-enabled profiling build
Section titled “Metrics-enabled profiling build”Maintainers build:
cargo build -p beskid_runtime --features metricsGenerated code that does not call rt_metrics_* still links because baseline JIT does not import optional symbols.
Engine dynamic extern (related)
Section titled “Engine dynamic extern (related)”cargo test -p beskid_engine extern_real_call_getpid --features extern_dlopenThis does not change runtime features; it documents cross-crate flag vocabulary for execution maintainers.
Release matrix documentation (prose)
Section titled “Release matrix documentation (prose)”Open VSX jobs should record in CI logs whether arrays_backing is enabled for the bundled runtime. Operators comparing local cargo build vs extension behavior should check that matrix before reporting array bugs.