feature - unsafe low-level operation surface 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 and kernel-facing work will need operations that safe Incan should not expose implicitly: raw pointers, volatile reads/writes, memory-mapped I/O, unchecked operations, and eventually target-specific intrinsics. Without an explicit unsafe surface, those operations would either be impossible or would leak through backend-specific code paths that tools cannot inspect.

The design work belongs to #682, but the 0.8 milestone also needs an implementation tracker for the first narrow unsafe operation slice after the RFC direction is accepted.

Proposed solution

Implement an experimental unsafe low-level operation surface v0 once the unsafe RFC direction is clear.

The first implementation should keep the surface deliberately small:

• parser/AST support for the accepted unsafe context shape;
• typechecker tracking of unsafe context;
• representation of unsafe operations in HIR/Body IR;
• raw pointer type shells or placeholders where required by the accepted RFC;
• volatile read/write support if needed for the 0.9 proof;
• diagnostics when unsafe operations appear outside an unsafe context;
• CLI/LSP/build-report visibility for unsafe sites.

Alternatives considered

• Hide low-level operations behind stdlib-only safe wrappers. Useful later, but insufficient for a kernel capability proof and for auditing target bring-up code.
• Let Rust interop or backend lowering produce unsafe implicitly. Rejected because the unsafe boundary must be visible in Incan source and tooling.
• Implement a broad systems-programming surface immediately. Rejected because 0.8 should prove the minimum surface needed for freestanding work.

Scope / acceptance criteria

• In scope:
  • Experimental unsafe context tracking after RFC proposal - unsafe blocks and low-level operations #682's RFC direction is accepted.
  • A narrow set of unsafe operations needed by freestanding smoke and 0.9 planning.
  • HIR/Body IR representation of unsafe operations.
  • Diagnostics and inspection output for unsafe sites.
• Out of scope:
  • Inline assembly.
  • Broad architecture intrinsic coverage.
  • Stable public unsafe syntax before the RFC settles.
  • Proving a production kernel safety model.
• Done when:
  • Unsafe operations are impossible outside an accepted unsafe context.
  • Unsafe sites are visible in compiler inspection/build-report output.
  • The first operation set is enough to support the planned 0.9 MMIO/volatile/raw-pointer proof or explicitly records what is still missing.
  • Existing safe Incan programs are unaffected.