vycdev / vycdev/jett

design: define initial HIR and monomorphization boundary

Open
#20 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
0
Forks
1
Avg merge
3d 13h
Merged PRs (30d)
108

Description

Summary

Define the first backend-neutral contract between Jett's checked program and jett_hir, including how concrete generic function instantiations are discovered, identified, deduplicated, and represented before MIR lowering.

Source documentation
Current state

Phase D is documented as not started, and the workspace has no jett_hir crate. The typechecker checks concrete generic function bodies on demand and interns generic struct instances, but its public CheckResult exposes only diagnostics, a span-to-type map, the type interner, and reflection metadata. The architecture describes HIR as consuming a TypedTree, but no such checked representation currently exists.

The tree-walking interpreter separately substitutes generic arguments while executing the source AST. Existing generic tests therefore validate parsing, checking, and interpretation, not a canonical monomorphization manifest or HIR lowering boundary.

Scope

This is a design and staging issue. It includes:

  • choosing the canonical checked-program representation consumed by HIR, whether that is a typed tree or a smaller checked AST plus compiler-owned maps;
  • defining stable function and concrete-instantiation identities, including discovery, deduplication, recursion, source spans, resolved parameter/return types, and invalid-call behavior;
  • defining the minimal initial HIR function/expression representation and which phase owns method resolution, desugaring, implicit views/copyability, and checked reflection metadata;
  • specifying how generic reflection specialization and trusted stdlib provenance cross the boundary without duplicating the policies tracked by #6 and #3;
  • splitting implementation into independently testable stages with deterministic HIR snapshots or equivalent structural tests.

It does not include MIR/CFG lowering, definitive MIR ownership verification, optimization, LLVM/native code generation, a runtime library, interpreter bytecode, or changing current source-language semantics. It also does not require implementing the full HIR before the boundary is accepted.

Acceptance criteria
  • A concrete checked-program-to-HIR input contract is recorded and reconciles the documented TypedTree with the typechecker's actual outputs.
  • Canonical generic-instantiation discovery, identity, ordering, deduplication, recursion, and diagnostic behavior are specified.
  • The initial HIR data model and ownership of the Phase 7 transformations are defined without moving language policy into backend-specific code.
  • Reflection facts and trusted stdlib origin have explicit handoff points coordinated with #6 and #3.
  • Staged implementation units and focused structural/snapshot tests are identified for multiple concrete instantiations, repeated calls, nested generic calls, constraints, methods, and rejected calls.
  • docs/design.md, 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
  • #3 owns module identity and trusted stdlib provenance; the HIR contract should consume, not redefine, that decision.
  • #6 owns any expansion of reflection-predicate specialization; HIR must preserve accepted checker facts without making arbitrary booleans into type proofs.
  • Should the first implementation expose a public typechecker instantiation manifest before introducing the jett_hir crate, or should both land as one vertical slice?

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

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with docs/progress.md, docs/architecture.md, and docs/design.md, then inspect the typechecker's current CheckResult and generic-checking outputs described in the issue. Define the checked-program-to-HIR contract, generic-instantiation rules, HIR ownership boundaries, and staged structural or snapshot tests. Done means the three documents and originating planning docs agree with the accepted boundary and implementation stages.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
compilers
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.