feature - layout repr and calling-convention metadata v0

[dannymeijer]

Area

• Incan Language (syntax/semantics)
• Compiler (frontend/backend/codegen)
• Tooling (CLI/formatter/test runner)
• Runtime / Core crates (stdlib/core/derive)

Problem statement

Freestanding targets, ABI-visible exports, Rust-facing packages, C/extern boundaries, boot protocols, and memory-mapped structures need explicit representation facts. Ordinary Incan types can remain layout-opaque, but low-level and boundary-facing code needs a way to say which layout, alignment, representation, and calling-convention facts are intentional.

The design work belongs to #683, but 0.8 also needs an implementation tracker for the first metadata and lowering slice after the RFC direction is accepted.

Proposed solution

Implement experimental layout/repr/calling-convention metadata v0 for ABI-visible declarations once the RFC direction is clear.

The first implementation should focus on metadata flow and validation before promising a stable public ABI:

• parser/metadata support for accepted representation and calling-convention declarations;
• typechecker validation for allowed declaration targets and invalid combinations;
• IncanType and ABI metadata facts for explicit representation choices;
• HIR/Body IR preservation of ABI-visible type/function properties;
• build report and semantic inspection output for representation facts;
• backend lowering for the minimum supported representation profiles.

Alternatives considered

• Keep layout entirely backend-owned. Rejected because ABI-facing and freestanding code needs intentional representation contracts.
• Make every model layout-stable. Rejected because it would freeze high-level application types too early.
• Treat Rust spelling as the contract. Rejected because Incan needs an Incan-owned ABI metadata model even when a Rust-compatible backend is used.

Scope / acceptance criteria

• In scope:
  • Experimental metadata for explicit layout/repr/calling-convention facts after RFC proposal - representation, layout, and calling convention controls #683's RFC direction is accepted.
  • Validation that unsupported combinations produce clear diagnostics.
  • ABI metadata and inspection output for explicit facts.
  • Minimum backend lowering needed by 0.8/0.9 proofs.
• Out of scope:
  • Stable public ABI guarantees.
  • Making ordinary Incan types layout-stable by default.
  • Full cross-target layout engine coverage.
  • Replacing Rust-facing ABI design in RFC - Rust-facing ABI and Cargo-native Incan package direction #656.
• Done when:
  • Explicit representation/calling-convention declarations survive parsing, checking, HIR/Body IR, ABI metadata, and inspection.
  • Unsupported or target-invalid representation choices produce diagnostics.
  • The minimum representation facts needed for freestanding smoke and 0.9 kernel proof planning are available or explicitly listed as blockers.
  • Ordinary types remain layout-opaque unless they opt into an explicit representation profile.