pub fn resolve_harness(
top: HarnessConfig,
opts: &ResolveOptions,
) -> Result<Resolved, ResolveError>Expand description
P3 CLI-wiring entry point (design §5.2 P3, “CLI load path resolves
config through the P2 resolver”): resolve an already-typed
HarnessConfig — e.g. one assembled by the CLI from its own
FileConfig’s forward-compatible extends/capabilities/experimental
fields, which are ALREADY sanitized/merged by userconfig.rs’s own
project-layer handling (sanitized_for_project/overlay_project) before
this ever sees them — so there is no second untrusted text layer to
merge here, unlike resolve. top.extends is still chased (steps
1-3) exactly as resolve does; when top.extends is None, callers
that want “no config file ⇒ supercode-default semantics” (design §4
intro: “supercode with no config file resolves to this preset”) must set
top.extends = Some("supercode-default".to_string()) themselves before
calling this — this function does not silently default it, since a
SILENT default would be exactly the kind of implicit behavior the
supercode-default preset exists to name instead of hide.