kiln-component does not compile in isolation: `cargo check -p kiln-component` fails on clean main (default = ["kiln-runtime/std"] never enables its OWN std feature)

[avrabe]

Summary

kiln-component fails to compile standalone on clean main — with default features and with --features std. The workspace build is green only because feature unification from sibling crates papers over it. Found while adding a regression test for #427: cargo test -p kiln-component cannot build, so the crate's tests are unrunnable in isolation.

Verified on main (8b9fa4b7) with a clean tree (no local changes).

Reproduction

$ cargo check -p kiln-component
error[E0433]: cannot find module or crate `std` in this scope     (x3)
error[E0599]: no method named `link_imports_lenient` found for struct `ComponentLinker`
error[E0599]: no method named `link_imports` found for struct `ComponentLinker`
error: could not compile `kiln-component` (lib) due to 5 previous errors

$ cargo check -p kiln-component --features std
error: could not compile `kiln-component` (lib) due to 4 previous errors

$ cargo check --workspace     # green — feature unification hides it

Root cause

kiln-component/Cargo.toml:

[features]
# By default, enable std to match kiln-runtime's default behavior
default = ["kiln-runtime/std"]

default enables the dependency's std, but never kiln-component's own std feature. So the crate compiles without feature = "std" set on itself, and everything behind #[cfg(feature = "std")] — including ComponentLinker::link_imports / link_imports_lenient and the std imports — disappears, while the call sites (e.g. component_instantiation.rs:946) remain unconditional. Hence E0433/E0599.

The comment says the intent was "consistent feature resolution across workspace and isolated builds" — it achieves the opposite: the isolated build is the one that breaks.

Impact

• cargo test -p kiln-component cannot run at all → the crate's tests only execute via a workspace-wide run; a targeted run (what a developer or a per-crate CI job would do) is broken.
• Any downstream consumer depending on kiln-component alone (an embedder — exactly the library-API audience of resolve_exports still panics via .expect() at component_instantiation.rs:2804 — #269/#271 panic-contract fix incomplete for the library API #427) gets a build failure.
• CI is green, so this is invisible: classic bit rot behind feature unification.

Suggested fix

default = ["std"] (and have kiln-component's own std feature enable kiln-runtime/std, which the std = [...] list already appears structured to do). Then add a per-crate isolated-build check (cargo check -p kiln-component --no-default-features / default / --features std) so unification can't hide it again. The remaining 4 errors under --features std need triage — the cfg'd methods may have drifted from their call sites independently.

Found while working #427 / SR-52 (PR #445).

[avrabe]

Partial fix in #462 (rivet SR-54), accumulating toward v0.4.3.

Fixed — the lib isolated build: default = ["kiln-runtime/std"] → default = ["std", "kiln-execution"]. It was enabling the dependency's std but never kiln-component's own std/kiln-execution, so cfg-gated items vanished. cargo check -p kiln-component now compiles standalone; cargo check --workspace still green; consumers (kilnd, kiln-wasi) unchanged.

remaining: the crate's test/example targets are separately, more deeply rotten — cargo test -p kiln-component --no-run still fails with ~47 type mismatches + references to removed APIs (execute_start, Component.options, ExternType::Function, task_manager, async_). These are stale test files that drifted across many refactors; fixing them is a larger fix-or-delete pass. Keeping this issue open for that half — a per-crate cargo test -p kiln-component --no-run gate should be added once the targets are cleaned, so unification can't hide this class again.