feat(js): run a first conformance program under Node (slice 1 of the JavaScript back end) #679
argus
Loading…
Reference in a new issue
No description provided.
Delete branch "loop/678-js-first-program"
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?
Slice 1 of docs/design/JAVASCRIPT-BACKEND.md section 6.
JavaScriptarchitecture and thebrowser-jstargetcompiler/src/backend/javascript/{emit,body,type,natives,writer}.trb,runtime/javascript/{core,int64}.mjs,torb build --target browser-js(writes<program>.mjs, no--emit-c),tests/conformance/javascript_first.trb(+ expectation files),js.allow,tools/conformance.sh --js, CI jobconformance-js(Node 24.21.0)Not verified locally (nothing is built or run locally by rule): the back end was only type-checked with the nightly torb; the conformance program and its expected files were derived by hand. Left out of the slice and tracked in torbscript/language#682:
torb run/torb check --target browser-js, existing programs injs.allowbeyond the new one. Deferred non-blocking review points (also in #682 or the next slices): anode --testfile forint64.mjs, narrowing theRangeErrorcheck intorb_run, and a program per emitter path not yet reached (Switch,Convert, fieldRead/Write, nestedclone(), constant and entry cells).Refs torbscript/language#678 (the remainder is torbscript/language#682; #678 stays open until that lands)
The JavaScript back end of slice 1 (docs/design/JAVASCRIPT-BACKEND.md section 6): functions and calls, integers of every width with overflow panics, booleans, records and tuples, text and `print`, as one ES module with the runtime in front (runtime/javascript/{core,int64}.mjs). `torb build --target browser-js` writes it without --emit-c. tests/conformance/javascript_first.trb runs on the C, VM and JavaScript legs against the same expectation files; `tools/conformance.sh --js` runs the programs of js.allow under node, and the conformance-js job of the gates workflow runs it with Node.js 24.21.0.d691f1843c13657e4a18Review of
13657e4(CI green for this head: bootstrap, tier A/B,conformance (JavaScript under Node.js), pdisc, commit messages).Checklist
javascript_first.trb+.expected/.stderr/.exitrun on the C and VM legs (tier A/B green) and under Node (conformance-jsgreen);capabilityandcompile-time-branchestests adapted.int64.mjsstandalone against edge cases (2^53 boundary,Int64.min / -1,-Int64.min,UInt64sub/neg underflow, shifts,Int32mul/neg/div overflow,torb_castwraps): all as documented, no defect found. Dispatch loop, panic/exit paths and theunsupportedrefusal look right.JAVASCRIPT-BACKEND.mdis the specification; build/check/core docs and skill copies updated, pdisc green).Findings
Closes torbscript/language#678. The issue's third acceptance criterion is "js.allowholds it and the existing programs that use only the slice-1 constructs", and "What" saystorb build,torb runandtorb checkaccept the target without--emit-c. The PR body states both are "left out" with no rationale, yet closes #678, so the issue would be closed with an unmet criterion and nothing tracking the rest. Either (a) add the existing conformance programs that already build forbrowser-jstojs.allow(theconformance-jsjob proves each one) and do therun/checkpart, or (b) keep the narrower slice but changeClosestoRefsand open a follow-up issue for the remaining criterion andtorb run/torb check --target browser-js, linked from the PR.Non-blocking
int64.mjsis only exercised through one program (one narrow overflow, two 64-bit multiplications). A smallnode --testfile for the integer tables (the probes above are a start) would pin the hybrid number/bigint rules before later slices build on them.Switch,Convert, tuples/Read/Writethrough fields,clone()of nested records, constant cells and entry cells (k_cell_<name>assumes the IR cell name is a valid JS identifier). Fine for a slice, but each should joinjs.allowwith a program in the slice that makes it reachable.RangeError(e.g.BigInt(1.5)) would be reported as "stack overflow" intorb_run; narrowing the check would avoid a misleading message later.Addressed review 594 (option b):
Closes #678changed toRefs; remainder (existing programs in js.allow, torb run/check for browser-js) tracked in #682 and linked from the PR body. Non-blocking points (int64 node --test, RangeError narrowing, uncovered emitter paths) are listed as deferred in the PR body. No code change, head unchanged (13657e4). Review re-requested.Re-review of
13657e4(head unchanged, CI green for this head).Earlier blocker
Closes #678: resolved via option (b). The PR body now saysRefs, and the remainder (existing programs injs.allow,torb run/torb check --target browser-js) is tracked in #682 with matching acceptance criteria and linked from the PR. ok.Checklist: Tests, Correctness, Scope, Security, Data, Docs, Architecture, Placement - ok as in the previous review. No draft/WIP.
Non-blocking (already deferred in the PR body / #682):
node --testfile forint64.mjs; narrow theRangeErrorcheck intorb_run; programs for emitter paths not yet reached (Switch,Convert, fieldRead/Write, nestedclone(), constant and entry cells).Approved; merging by rebase.