Which traps one exported function can actually reach #

Reads off the syntax the trap codes a call of one exported function can throw.

The .d.ts is where a consumer decides whether to write a try. One line naming every code the subset has tells them nothing: a function that only adds and multiplies carries divByZero beside a function that divides, so the comment stops being a reason to catch anything. What is worth reading is the codes this function can reach.

Reaching is read off the syntax, the way the fuel bound is. Each operation contributes the codes its case in Eval can return, a call contributes the callee's, and a declaration handed over as a function contributes its own at the call that hands it over -- which is where the invariant lives: a function-typed parameter is only ever bound to a declared name passed as an argument, so a call through such a parameter adds nothing the caller has not already counted.

noMatchingAlternative is not among them. Exhaustive proves a match the compiler accepted has an arm for every value the entry check lets through, and a fold's alternatives one for every node its walk rebuilds, so the generated chain never runs off the end.

This is not proved, and emit does not take it on trust: every vector generated for a declaration is checked to trap only with a code this reads off it.