feature - freestanding target profiles and runtime requirement reports

[dannymeijer]

Area

• Compiler (frontend/backend/codegen)
• Tooling (CLI/formatter/test runner)
• Runtime / Core crates (stdlib/core/derive)
• Documentation

Problem statement

The 0.8 roadmap needs Incan to compile restricted freestanding artifacts and report which runtime, allocator, panic, target, and ABI capabilities they require. Today those requirements are not a first-class compiler contract. They are scattered across type information, stdlib/runtime helpers, emitted Rust assumptions, package metadata, and build behavior.

Without target profiles and requirement reports, freestanding support would be backend folklore: users would discover unsupported hosted APIs only after codegen or target-specific build failures.

Proposed solution

Add an experimental target-profile and runtime-requirement reporting path for 0.8. This should let the compiler represent a selected target profile, collect runtime/helper/package requirements from semantic facts, HIR, Body IR, ABI metadata, and stdlib/runtime layer metadata, and report why a program is or is not compatible with the selected target.

The first implementation should be deliberately narrow and should align with the future RFC from #681.

Expected shape:

• a target-profile model for hosted versus freestanding builds;
• requirement facts for runtime layer, allocator, panic behavior, target triple/profile, ABI/layout needs, and hosted capabilities;
• diagnostics when source or dependencies require capabilities unavailable in the selected target profile;
• build report and semantic inspection output exposing these facts;
• package metadata hooks so dependencies can declare their target/runtime requirements.

Alternatives considered

• Treat freestanding as a backend-only flag. Rejected because stdlib imports, dependency compatibility, diagnostics, package metadata, and build reports need the same facts.
• Wait until the 0.9 kernel proof to discover requirements. Rejected because the kernel proof should validate foundations, not invent them under pressure.
• Infer everything from emitted backend artifacts. Rejected because the larger roadmap explicitly retires generated Rust as the semantic handoff.

Scope / acceptance criteria

• In scope:
  • Define an experimental target-profile data model for hosted and freestanding profiles.
  • Collect runtime/helper/allocator/panic/target/ABI requirements from compiler-owned facts where available.
  • Emit machine-readable and human-readable requirement reports.
  • Produce diagnostics for hosted-only requirements under a freestanding profile.
  • Integrate with chore - stdlib/runtime layer inventory for freestanding foundations #684's stdlib/runtime layer inventory and the design direction from RFC proposal - freestanding targets and runtime layering #681.
• Out of scope:
  • Final stable target-profile syntax.
  • Full no-std backend support by itself.
  • Unsafe operation syntax or layout/calling-convention syntax.
  • Kernel boot work.
• Done when:
  • A representative hosted program reports hosted requirements accurately.
  • A restricted freestanding candidate reports only allowed runtime requirements or explains every blocker.
  • Build reports and semantic inspection expose target/runtime requirement facts.
  • Follow-up no-std build-mode work can consume the same target-profile facts instead of adding a separate mechanism.