chore - stdlib/runtime layer inventory for freestanding foundations

[dannymeijer]

Area

• Runtime / Core crates (stdlib/core/derive)
• Compiler (frontend/backend/codegen)
• Documentation

Summary

Inventory the current stdlib and runtime surfaces against the future freestanding runtime-layer model. The goal is to classify which pieces can live in a minimal core layer, which require allocation, which require hosted std, and which should remain target-specific or deferred until kernel-facing work.

This is the 0.8 counterpart to #646's behavior inventory. #646 records hidden hosted assumptions in current compiler behavior; this chore turns that evidence into an explicit stdlib/runtime layering map before implementation work starts.

Scope

• In scope:
  • Classify current stdlib modules and runtime helpers as core-safe, alloc-requiring, hosted-std-requiring, target-specific, or deferred.
  • Identify hidden dependencies on filesystem, process, environment, threads, default allocator, hosted panic behavior, wall clock, randomness, and networking.
  • Identify which APIs can be available in freestanding profiles and which should produce target-profile diagnostics.
  • Record candidate layer names and boundaries for the future RFC from RFC proposal - freestanding targets and runtime layering #681.
  • Link follow-up implementation issues where runtime/helper changes are needed.
• Out of scope:
  • Implementing no-std/freestanding compilation.
  • Moving runtime code between crates before the layer model is accepted.
  • Defining unsafe/layout/calling-convention syntax.
  • Kernel boot work.
• Risks:
  • Treating hosted conveniences as core-safe would weaken the 0.8 target model.
  • Over-splitting too early could create churn before the backend cutover evidence exists.

Plan

1. Use chore - current compiler behavior inventory for backend replacement #646, current stdlib source, runtime helper usage, and generated artifact reports as inputs.
2. Build a module/helper inventory with required runtime layer and host capabilities.
3. Mark unknowns explicitly instead of assuming hosted std.
4. Identify the smallest useful core/alloc/hosted split for 0.8.
5. Feed the result into the freestanding targets/runtime layering RFC and follow-up implementation issues.

Done when

• A stdlib/runtime layer inventory exists and is linked from the 0.8 freestanding work.
• Each current stdlib module or runtime helper has a provisional layer classification or explicit unknown status.
• Hosted-only assumptions are visible enough for target-profile diagnostics and freestanding build-mode planning.
• Follow-up implementation issues are linked where code movement or metadata work is required.