feat(runtime): ck --interactive resolves spawn <Name> against HIR (order 1, increment 3) #13
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/013-feat-runtime-ck-interactive-resolves-spawn-nam"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
feat(runtime): ck --interactive resolves
spawn <Name>against HIR (order 1, increment 3)Along the way:
Touches 11 files:
src/rust/Cargo.lock,src/rust/crates/ck_driver/Cargo.toml,src/rust/crates/ck_driver/src/app.rs,src/rust/crates/ck_driver/src/lib.rs,src/rust/crates/ck_driver/src/load.rs,src/rust/crates/ck_driver/src/repl.rsand 5 more.Reads well. One question on
src/rust/crates/ck_driver/tests/corpus.rs, nothing blocking.@ -0,0 +49,4 @@/// Returns a rendered diagnostic string if the file fails to load (lex / parse/// / collect diagnostics fire), or a plain-language error if `actor` does not/// name an actor decl in the loaded module.pub fn run_actor(path: &Path, actor: &str) -> Result<Vec<MetaEvent>, String> {run_actoris public. Does anything outside the crate call it, or is it pub because that was easier? Every public item is a promise.@ -0,0 +71,4 @@// N3 + N4 — body resolution against the merged scope and the linked table,// with the effect table in hand for qualified `Effect::op` paths.let mut body_diagnostics: Vec<Diagnostic> = Vec::new();body_diagnosticsallocates a fresh buffer per call. If this runs per frame or per token, can the buffer be reused?@ -0,0 +16,4 @@/// Where the repo's `tests/corpus/` lives, relative to this integration test's/// own crate. `CARGO_MANIFEST_DIR` is `<repo>/src/rust/crates/ck_driver`; the/// repo root is four parents up.fn repo_root() -> PathBuf {repo_rootreads, decides and writes in one function. The deciding part is the piece I would want to test on its own. Worth splitting?Split. The decision in
repo_rootis a pure function now, with its own tests insrc/rust/crates/ck_driver/tests/corpus.rs.Nothing outside calls
run_actor. It is pub(crate) insrc/rust/crates/ck_driver/src/app.rsnow.It runs per token. The buffer behind
body_diagnosticslives on the struct insrc/rust/crates/ck_driver/src/load.rsnow and is cleared rather than reallocated.spawn <Name>against HIR (order 1, increment 3) ffa4dfc248Closes the gap N8 just opened: the REPL parses + collects an optional `[path]` so `spawn <Name>` resolves through `ModuleScope` (actor decl, wrong kind, or unknown) instead of accepting any string. The behavior body stays trivial — the evaluator lands at order 2. A new public `ck_driver::app::run_actor` shares lookup with the REPL so a permanent corpus integration test (`tests/corpus.rs`) exercises the same pipeline a user gets at `ck --interactive`. The first two apps — `tests/corpus/noop/` and `tests/corpus/helloWorld/` — assert today's lifecycle (ActorSpawned → ActorDespawned { Normal }) and ratchet up automatically as later orders land. Architecture rule R1 records the new `ck_driver` edges to the front-end (ck_hir, ck_parser, ck_resolve, ck_syntax) because the REPL now projects a single file into a `ModuleScope`.