source-academy / py-slang / 31150017757

86%

push

github

Stepper: pop-ups for module functions, imported and generated (#406, #407) (#412)

* Stepper: give §2 library functions a real Function definition popup

llist_ref (and map, filter, reduce, append, ... and their _-prefixed
helpers) never showed a hover popup, unlike a user-defined function.
The mystery: they're written in lists.ts as lambda/def AST templates,
but that's an implementation detail internal to applyLibrary -- a
call dispatches through BUILTIN_FUNCTIONS as a one-step JS-native
expansion (confirmed: calling llist_ref shows "Running llist_ref" /
"Ran llist_ref" as a single contraction, then the substituted body
continues stepping normally). The template itself never becomes an
actual ArrowFunctionExpression/FunctionDeclaration node anywhere in
the displayed tree, so functionValues (which already gives every
user-defined function its mu-term + popup) has nothing to attach to.

This is the opposite problem from #404 (a true builtin has no body to
show at all, so it gets a fixed-text popup instead) -- and needed a
different fix: teach getSteps.ts's existing display-time relabeling
pass (markBuiltins, from #409) to distinguish the two. Generalized
markBuiltins to take a resolver (name) => StepNode | undefined instead
of a plain boolean predicate:

- builtins.ts's new resolveBuiltinDisplayValue checks
  lists.ts's newly-exported getListLibraryTemplate(name) first (the
  real template, for map/_map/llist_ref/...), falling back to the
  existing Builtin+hoverText node for a true native builtin.
- markBuiltins now recognises when the resolved node is a real
  function-value shape (ArrowFunctionExpression/FunctionDeclaration):
  it tags it with a name marker and recurses into its own body too
  (own name+params added to the shadowing-safety `bound` set, exactly
  like the existing cases), so a library function used as a bare
  value collapses to a mu-term with the real "Function definition"
  popup, and any *other* library name it references (e.g. _m... (continued)

4789 of 5993 branches covered (79.91%)

Branch coverage included in aggregate %.

16 of 17 new or added lines in 2 files covered. (94.12%)

10698 of 11973 relevant lines covered (89.35%)

164710.95 hits per line