RFC 119: Oven-native Rust build facets and Cargo interoperation

[dannymeijer]

Intent

RFC 119 is a full v0.6 commitment. Oven must provide a serious, Cargo-independent Rust build system for explicitly supported Rust Loaves without adopting Cargo manifest or publication authority.

Scope

• Define and implement the complete Oven-native Rust facet: package/crate identities, roots, editions, crate types, binary entrypoints, features, target conditions, profiles, dependency roles, linkage, tests, examples, doctests, and benchmarks.
• Resolve crate dependencies from crates.io and registered Cargo-compatible sources through explicit providers with locked/offline, trust, integrity, host/target, and feature-resolution facts.
• Keep build.rs inert: never compile, execute, or interpret it in Oven-native mode. Declare its former cfg/generated/native/tool requirements in Loaf manifests, with publisher-side harvest and explicit native/tool bake units owned by chore - v0.6 Slice 6: Loaf-native ecosystem, build scripts inert #1561.
• Preserve procedural-macro host execution as a separate contract with typed inputs, outputs, host identity, policy, diagnostics, and receipts.
• Plan Rust compiler/toolchain, sysroot, linker, and platform packaging directly to produce target-bound Loaf assets.
• Derive Rust-analyzer-compatible project metadata from Oven facts.
• Implement explicit Cargo adoption and compatibility: oven cargo remains Cargo-authoritative; an existing Cargo project must opt into Loaf adoption and is never implicitly merged.
• Establish the complete host, cross-target, workspace, feature, cache, offline, relocation, failure, and Cargo-compatibility conformance matrix.

Boundaries

• Oven-native Loaves and Loaf assets are not published to crates.io.
• Cargo manifests, lockfiles, workspace discovery, and arbitrary Cargo execution are not ordinary Loaf semantics.
• Incan-first authoring remains in force: a Rust facet does not require authored Rust.
• RFCs 097, 117, and 118 retain the caller ABI, project, artifact, and command-surface contracts.

Delivery

• feature - RFC 119 native Rust facets and direct-rustc planning #1037 — native Rust facets and direct-rustc planning
• feature - RFC 119 typed proc-macro providers under the inert-build-script model #1035 — typed proc-macro providers under the inert-build-script model
• chore - v0.6 Slice 6: Loaf-native ecosystem, build scripts inert #1561 — inert build scripts, declared cfg/out/native/tool inputs, harvest, and ecosystem conformance
• feature - RFC 119 Rust roles, IDE projection, Cargo adoption, and conformance #1040 — Rust roles, IDE projection, Cargo adoption, and conformance

Done when

• Explicit Rust source Loaves pass the complete RFC 119 conformance corpus without Cargo metadata dependency.
• Cargo is an explicit adoption or compatibility boundary, never the normal Oven authority.
• Plans, artifacts, IDE projections, diagnostics, and receipts derive from one Oven graph.

[dannymeijer]

Accepted design decision — generic Rust build-time providers

Evidence audit (2026-08-10)

• Incan has no authored build.rs, but its resolved Rust graph contains 84 build-script targets and 31 proc-macro targets (including test and target-specific units). Normal dependencies include native compilation: blake3 and the selected wasmtime closure use cc; test coverage also brings zstd-sys and lzma-sys.
• IncQL's locked Rust closure has 46 build scripts and 25 proc macros. Its Substrait closure generates Rust sources, invokes git for a source checkout, and, through protobuf-src, invokes CMake to build protoc. It also contains native/sys dependencies such as zstd-sys and liblzma-sys.
• Hees.ai's locked closure has 31 build scripts and 8 proc macros. Its TLS path contains rustls → ring → cc; ring compiles native/assembly code, writes generated output, and emits link facts.
• Representative scripts require ordinary protocol facts: rerun source/environment inputs, cfg/check-cfg facts, generated outputs, diagnostics/warnings, link search paths, link libraries, and controlled compiler probes.

Decision

1. A build-script or proc-macro target discovered from selected crate metadata is a provider candidate, never self-authorized execution.
2. Oven supplies generic, typed host-provider roles: rust.build-script and rust.proc-macro. They run in isolated staging with locked source, feature, host/target, toolchain, arguments, environment, outputs, normalized directives, diagnostics, and observed effects captured in a provider receipt.
3. The generic provider has no implicit Cargo fallback and no opaque directive passthrough. The initial normalized vocabulary is: rerun inputs, cfg/check-cfg, controlled environment outputs, generated-input locations/digests, warnings/diagnostics, and native link search/library/argument facts. Unknown directives diagnose.
4. Native compilation/linking, system probing, and named external tools are separate effect classes within that provider envelope (for example native.cc, native.pkg-config, tool.cmake, tool.protoc, and tool.git). A package can report these needs but cannot grant them.
5. In the default observe mode, Oven may execute the selected provider and record its actual effect facts in the receipt; governed mode requires the Loaf policy to grant each expanded effect class, and permissive remains an explicit escape hatch. A denial must identify the crate, command/effect class, policy mode, and the exact grant that would admit it.
6. Provider cache identity starts conservatively with the whole permitted package input tree, selected features, host/target, approved environment/tool identities, provider version, and output/receipt digests. Rerun directives refine inspection and later invalidation; they are not assumed to capture every dynamic read on first execution.

This resolves RFC 119's provider-admission and initial directive-vocabulary boundary. It does not settle the platform-specific dynamic-loading/process-isolation mechanism for procedural macros; that remains RFC 119 unresolved question 3 and requires an executable host conformance proof.

[dannymeijer]

RFC 119 is decision-complete and moved to Planned: 119_oven_native_rust_build_facets_and_cargo_interoperation.md, commit 123e4ed.

All 4 unresolved questions resolved, plus the carrier-selection-criterion item carried forward from the RFC 092 audit:

• Carrier-selection criterion — no. Splitting a project's code into different build outputs is done by physically separating Loaves under RFC 117's workspace model, the same idiom Rust (separate crates) and Python (separate sub-packages) already use.
• Q1 — rust.* exceptions describe only a Loaf's own single compilation unit plus additional build roles (extra binaries alongside one library), never a second crate identity. A genuinely separate crate (most commonly a proc-macro) is a sibling Loaf referenced as a loaf-kind dependency with a path origin — not a nested manifest table.
• Q2 — governed-mode containment delegates to existing platform-native sandboxing primitives (Landlock/bubblewrap on Linux, sandbox-exec on macOS, AppContainer/Job Objects on Windows) rather than Oven building its own; governed mode is refused outright where no viable primitive exists.
• Q3 — crate/provider promotion from Cargo-only to Oven-native reuses the existing conformance-corpus mechanism at crate/provider grain, rather than inventing a separate promotion process.
• Q4 (dissolved) — removes speculative "bakery.io" mentions entirely. incan.pub already holds more than plain Loaves (crates, mixes, templates), so a separate registry brand was never warranted.

Also fixes the Target scope header (was v0.8, now v0.6, matching its milestone and RFC 117), and clarifies where Oven-native's real advantage over Cargo comes from: avoiding redundant rebuilds across equivalent environments via receipt-keyed reuse, not raw single-build speed — and that benefit, like the receipted project model, is exclusively native-mode.

RFC 117, 118, and 119 are all Planned now. Next: RFC 090 (typed CLI framework), added to this pass as pre-work for RFC 118's v0.7 shipment.