Skip to content

feature - panic strategy and allocator hooks for freestanding targets #689

@dannymeijer

Description

@dannymeijer

Area

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

Problem statement

Freestanding targets cannot assume the ordinary hosted panic path or a default allocator. A restricted artifact may need panic = abort, a custom panic halt/report hook, no allocator, a provided allocator, or an allocator initialized by target-specific code. If this remains implicit, no-std builds and kernel-facing work will fail late or depend on backend accidents.

#686 needs minimal panic and allocator handling for a smoke artifact, but 0.8 also needs a dedicated hook model so target profiles, package metadata, runtime layers, and diagnostics agree on what a program requires.

Proposed solution

Add experimental compiler/runtime hooks for panic strategy and allocator requirements under freestanding target profiles.

The first slice should define and plumb:

  • panic strategy metadata, such as hosted unwind/report, abort, halt, or target-provided handler;
  • allocator requirement metadata, such as none, compiler/runtime-provided, package-provided, or target-provided;
  • diagnostics when code requires allocation or panic behavior unavailable under the selected target profile;
  • build report fields for panic and allocator requirements;
  • a minimal target-provided panic/allocator hook path where required by feature - no-std freestanding build mode and restricted artifact smoke test #686 and the 0.9 proof.

Alternatives considered

  • Treat panic and allocator behavior as backend flags only. Rejected because packages, diagnostics, and target profiles need visible requirements.
  • Require every freestanding artifact to provide an allocator. Rejected because many tiny proofs should be allocation-free.
  • Defer this to the kernel proof. Rejected because allocator and panic assumptions should be resolved before QEMU boot work.

Scope / acceptance criteria

  • In scope:
  • Out of scope:
    • Stable public syntax for all panic/allocator policies.
    • General-purpose allocator implementation.
    • Full unwinding support on freestanding targets.
    • Production kernel panic subsystem.
  • Done when:
    • A freestanding target profile can declare accepted panic and allocator strategies.
    • Code that requires unsupported allocation or panic behavior is rejected with a clear diagnostic.
    • Requirement reports expose the chosen panic and allocator strategy.
    • The restricted freestanding smoke test can use the hook model instead of hardcoded backend behavior.

Metadata

Metadata

Assignees

No one assigned

    Labels

    featureNew feature or requestincan compilerSuggestions, features, or bugs related to the Compiler (frontend/backend/codegen)runtime / core cratesSuggestions, features, or bugs related to the `incan-core`, `incan-stdlib`, 'incan-derive` cratestoolingSuggestions, features, or bugs related to the Tooling (CLI/formatter/test runner)
    No fields configured for Feature.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions