Every host compilation must see the standard library graph.
Contracts and edge cases
Platform spec article
Contracts and edge cases
Spec standingStandard
-
Parser rejects noCorelib and useCorelib false.
Context
Decision
Rule Detail Forbidden keys noCorelib,useCorelib: falserejected at parseTemplates Scaffolds must not emit opt-out keys Consequences
Implicit injection in
resolve_dependenciesalways attaches corelib.Verification anchors
projects/parser.rs; template manifest tests. -
Corelib member packages must not implicit-back-link to aggregate.
Context
Shards under
packages/*would create cycles if they gained implicit host edges.Decision
Rule Detail Guard is_corelib_workspace_shard_manifestskips implicit back-edgeHost Only application hosts receive implicit corelib Consequences
Building
packages/runtimealone does not pull beskid_corelib as a hidden parent.Verification anchors
resolver.rs; corelib workspace compile tests. -
Compiler mods compile as carriers without host corelib rules.
Context
Mods are not end-user hosts; injecting corelib would distort mod graphs.
Decision
Rule Detail ModDoes not receive implicit host injection HostReceives implicit corelib per D-CORE-COMP-0005 Consequences
Mod SDK projects declare their own dependency closure.
Verification anchors
Mod project tests in
beskid_tests. -
CLI and LSP share corelib discovery and graph options.
Context
IDE analysis must match CLI compilation attachment.
Decision
Rule Detail CLI ensure_corelib_readybefore commandsLSP CompilationContext::try_for_analysis_path_with_graph_optionsConsequences
Diagnostic drift between CLI and LSP indicates a resolver bug.
Verification anchors
LSP workspace tests;
corelib/compile.rs.
- Contracts and edge cases Corelib injection guarantees and edge cases.
- Design model How the compiler injects and resolves the corelib package into host compilations.
- Examples Observable corelib injection scenarios.
- FAQ and troubleshooting Corelib injection and resolution FAQ.
- Flow and algorithm End-to-end flow for corelib injection during project graph resolution.
- Verification and traceability Tests and traceability for corelib injection and resolution.
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).
Contracts
Section titled “Contracts”- No opt-out — Host manifests must not disable corelib; parser rejects forbidden keys.
- Single aggregate identity — Implicit attachment targets
beskid_corelib/ package namecorelib, not arbitrary forks, unless explicitly overridden by a declaredStdpath dependency in advanced layouts. - Transitive closure — Host compilations must see the full corelib workspace member packages required by the aggregate manifest.
- Mod projects —
Modpackages do not receive implicit host injection rules; they compile as mod carriers, not application hosts. - Template output — Instantiated host projects from templates follow host rules (implicit corelib).
Edge cases
Section titled “Edge cases”| Case | Behavior |
|---|---|
Explicit Std dependency | Used instead of fallback path when path provided |
beskid_corelib building itself | is_std_project / manifest path checks avoid self-cycle |
Shard under packages/runtime | No implicit back-link to aggregate |
Missing BESKID_CORELIB_ROOT in CI | Repo discovery or bundled CLI corelib materialization |
Legacy standard_library paths | Tooling may accept aliases; canonical identity remains corelib |
Relationship to discovery feature
Section titled “Relationship to discovery feature”Packaging, readme, and pckg publish rules live under Corelib discovery and packaging; injection assumes those roots exist on disk or in cache.