design: define initial MIR CFG and ownership boundary

[vycdev2]

Summary

Define Jett’s first backend-neutral HIR-to-MIR contract: a deterministic control-flow-graph representation, the constructs it must lower, and the definitive ownership-verification boundary before future optimization and code generation.

Source documentation

• docs/progress.md — Phase D: Code Generation
• docs/architecture.md — Phase 8: Mid-Level IR
• docs/architecture.md — Ownership Analysis
• docs/architecture.md — Phase D implementation plan

Current state

Phase D records jett_mir as not started, and the workspace has no MIR crate or Rust definitions for basic blocks, places, operands, rvalues, or terminators. The architecture sketches MIR as a CFG fed by HIR, but it does not yet define stable function/local/block identities, source mapping, complete control-flow lowering, or validation invariants.

Ownership checking currently runs over the parser AST after type checking, tracks variables by source name, and emits diagnostics without exporting ownership facts. The architecture assigns definitive ownership verification to MIR, including complex control-flow joins, but the handoff between the early AST check and that future CFG dataflow pass remains undefined.

Scope

This is a design and staging issue. It includes:

• defining the exact HIR facts consumed by MIR after design: define initial HIR and monomorphization boundary #20, with HIR owning generic instantiation discovery and other accepted Phase 7 transformations;
• specifying the initial MIR identities and data model for concrete functions, locals and places, operands and rvalues, basic blocks, statements, terminators, types, and source spans;
• defining deterministic lowering and validation invariants for straight-line code, conditionals, loops and back-edges, break, continue, explicit and early returns, and handle control flow;
• defining the CFG dataflow contract for existing ownership states, moves, views, clones, drops, branch joins, loops, and structured-concurrency cleanup without changing source-language policy;
• deciding which checks remain useful early diagnostics and making MIR verification the final ownership gate before later backend phases;
• splitting implementation into independently testable stages with deterministic structural or snapshot tests.

It does not include redefining HIR or monomorphization, inventing new ownership or control-flow semantics, optimization, LLVM/native code generation, the runtime, bytecode, or migrating the current tree-walking interpreter. Advanced constructs may be staged explicitly rather than requiring every lowering in the first implementation.

Acceptance criteria

• The HIR-to-MIR input contract is recorded and explicitly depends on the concrete function and instantiation identities accepted in design: define initial HIR and monomorphization boundary #20.
• The initial MIR data model, stable ordering, source-span mapping, and structural validation invariants are defined.
• CFG lowering ownership is specified for the initial control-flow subset, including branches, loops, early exits, and handle paths.
• Definitive ownership dataflow defines moves, views, clones, drops, joins, loop fixed points, and pending-task cleanup using existing language policy.
• The division between AST/HIR diagnostics and the final MIR ownership gate is explicit.
• Staged implementation units and focused tests cover well-formed and malformed MIR plus representative ownership joins and exits.
• docs/architecture.md and docs/progress.md are updated to match the accepted boundary and status.
• The originating planning docs remain in place and reflect the issue’s final status.

Dependencies / open questions

• design: define initial HIR and monomorphization boundary #20 defines the checked-program/HIR and monomorphization boundary that MIR must consume; MIR implementation should not precede an accepted concrete HIR input contract.
• How small can the initial lowering subset be while still exercising nontrivial branch joins and producing a stable contract for later optimization and codegen?

This was generated by an AI agent (vycdev2). Please verify any changes before merging or applying.