docs: RFC 0006 — mark unions/user-fns/positions/default-on resolved

Update the status, strictness levels, and open questions to reflect what
landed: bounded unions (jolt-pz5), user-fn domains behind
JOLT_TYPE_CHECK_USER (jolt-zo1), precise file:line:col (jolt-fqy), and the
checker folded into one inference walk that piggybacks on direct-link
specialization (on by default there, opt-in in plain builds). Align the
error-reporting example with the actual output format.
This commit is contained in:
Yogthos 2026-06-13 13:47:36 -04:00
parent 088232b778
commit e071d09170

View file

@ -1,9 +1,14 @@
# RFC 0006 — Compile-time detection of provably-wrong code (success typing) # RFC 0006 — Compile-time detection of provably-wrong code (success typing)
- **Status**: Implemented (jolt-y3b), first table. Core-fn error domains - **Status**: Implemented. Core-fn error domains (arithmetic on non-numbers,
(arithmetic on non-numbers, count/first/rest/next/seq/nth on non-seqable count/first/rest/next/seq/nth on non-seqable scalars), `JOLT_TYPE_CHECK=
scalars), `JOLT_TYPE_CHECK=off|warn|error`, decoupled from specialization. off|warn|error`. Follow-ups landed: bounded scalar **unions** (jolt-pz5) so a
Precise source locations (file:line:col) remain follow-up work. use is reported only when every member is in the error domain; **user-fn
error domains** behind `JOLT_TYPE_CHECK_USER` (jolt-zo1, closed-world);
precise **file:line:col** locations (jolt-fqy). The checker is now one
inference walk (folded into `infer`), and is **on by default in direct-link
builds** — where it piggybacks on the specialization inference for ~free —
and opt-in (`JOLT_TYPE_CHECK`) in plain builds.
- **Champions**: jolt maintainers - **Champions**: jolt maintainers
- **Created**: 2026-06-13 - **Created**: 2026-06-13
- **Depends on**: RFC 0005 (structural collection-type inference) - **Depends on**: RFC 0005 (structural collection-type inference)
@ -112,8 +117,7 @@ A reported error includes:
Example: Example:
``` ```
type error at scene.clj:42:18 type error scene.clj:42:18: `inc` requires a number, but argument 1 is a string
(inc total) — `inc` requires a number, but `total` is a string
``` ```
Errors are attributed to the form the user wrote. For macro-expanded code, the Errors are attributed to the form the user wrote. For macro-expanded code, the
@ -122,14 +126,20 @@ tracks `:error-pos`), never at synthesized internals.
## Strictness levels ## Strictness levels
A single env/compile flag controls behavior, defaulting to non-breaking: `JOLT_TYPE_CHECK` controls behavior:
- **off** — no checking (default for now). - **off** — no checking.
- **warn** — report to stderr, do not fail compilation. The recommended rollout - **warn** — report to stderr, do not fail compilation. **The default in
default once the table is trusted. direct-link builds**, where checking rides the specialization inference for
~free; opt-in elsewhere.
- **error** — fail compilation on a provable type error. Opt-in for CI / strict - **error** — fail compilation on a provable type error. Opt-in for CI / strict
builds. builds.
When `JOLT_TYPE_CHECK` is unset, checking is **on (`warn`) in direct-link
builds** and **off in plain REPL/dev builds** (where it would cost a standalone
inference pass, ~2.6× compile). `JOLT_TYPE_CHECK_USER` additionally enables
reporting against inferred user-function domains (closed-world; see below).
Because the checker only fires on provable errors, even `error` mode cannot Because the checker only fires on provable errors, even `error` mode cannot
break a correct program: a correct program has no provable type errors to break a correct program: a correct program has no provable type errors to
report. (A correct-but-untypeable program is simply not reported, since its report. (A correct-but-untypeable program is simply not reported, since its
@ -193,26 +203,28 @@ smallest high-confidence table (arithmetic and seq/count/nth/first), and grow.
destroys trust. Mitigation: start tiny, test each entry against the runtime, destroys trust. Mitigation: start tiny, test each entry against the runtime,
grow slowly. Open question: derive the table from the same machinery the grow slowly. Open question: derive the table from the same machinery the
runtime uses, to avoid drift? runtime uses, to avoid drift?
- **Unions.** Today the inference joins to `:any` rather than forming unions - **Unions.** *Resolved (jolt-pz5).* The lattice has a bounded scalar union
(`{:num | :str}`). Precise success typing wants unions (report only when `{:union #{T...}}` (cap 4); differing if-branches form a union instead of
*every* member is in the error domain). Open question: add a small bounded collapsing to `:any`, and a use is reported only when *every* member is in the
union type to RFC 0005's lattice, or keep `:any` and lose some precision (more error domain. Unions are opaque to structural specialization, so codegen is
conservative, fewer reports, still no false positives)? Proposed: start with unchanged.
`:any` (conservative), add unions if too many real errors are missed. - **User-function signatures.** *Resolved (jolt-zo1), opt-in.* Behind
- **User-function signatures.** Reporting against inferred user-fn domains is `JOLT_TYPE_CHECK_USER`: the checker re-checks a registered non-redefinable
more powerful but rests on the closed-world assumption and on the inferred user fn's body with one parameter bound to its concrete argument type; a
signature being a true requirement. Proposed: core fns first; user fns behind diagnostic the all-`:any` body did not have means that argument is provably
an explicit opt-in. wrong. Monotonic, so still no false positives; closed-world, hence opt-in.
- **Negative/never types.** Some "provably wrong" cases are about a value being - **Negative/never types.** Still open. Some "provably wrong" cases are wrong
the wrong arity or a fn vs a non-fn (calling a non-function). Worth including arity or a non-fn called as a fn; worth including the clear ones (calling a
the clear ones (calling a `:num` as a function) since the inference already `:num`) since the inference knows function-ness.
knows function-ness. - **Position vs intent.** *Resolved (jolt-fqy).* The reader records each list
- **Position vs intent.** Reporting at the right source location through form's absolute offset (identity-keyed, so positions survive macroexpansion
inlining and macro expansion needs the position metadata to survive the exactly when the user's sub-form is spliced through); the analyzer stamps it
passes. The loader tracks `:error-pos`; the IR may need to carry form onto `:invoke` nodes, the checker carries it into each diagnostic, and the
positions for precise column reporting. back end renders `file:line:col`. Inlining/scalar-replace preserve it via
- **Interaction with the optimization gate.** The inference currently runs only `assoc`.
in optimization mode. The checker is valuable in normal builds too, so the - **Interaction with the optimization gate.** *Resolved (jolt audit).* The
inference (at least its intra-procedural, sound-without-closed-world part) checker is one inference walk folded into `infer`. In direct-link builds it
may need to run for checking even when specialization is off. Open question: piggybacks on the specialization inference that already runs (~free, default
decouple "run inference for checking" from "specialize from inference". on); in plain builds it runs as a standalone pass only when `JOLT_TYPE_CHECK`
is set. "Run inference for checking" and "specialize from inference" are the
same walk now, gated by a `checking?` flag.