source-academy / py-slang / 31155376990

86%

push

github

Stepper: reject a def/assignment that redeclares an import (#416)

* Stepper: reject a def/assignment that redeclares an import

py-slang#413: `from rune import red` followed by a local `def
red(x): return x` and then `print(red(4))` crashed the substitution
stepper with a conductor-level "Invalid opaque identifier: 4" instead
of being rejected outright.

Both the import and the def live at the program's top level.
Reassignment isn't allowed in Python §1/§2 -- deliberately: those
chapters are designed so substitution alone is a sufficient
explanation model, with no environment/mutation reasoning required --
and Python §3/§4, where reassignment is allowed, don't have a
stepper. So this program should never have been accepted in the first
place, the same as `x = 1` followed by `x = 2` already isn't.

createNoReassignmentValidator (wired in for chapters 1-2 only) only
ever inspected Assign/AnnAssign/FunctionDef targets to decide what's
already declared in a scope. `from rune import red` was invisible to
it, so the later `def red` sailed through preprocessing undetected,
and the program only failed later -- confusingly -- once the
substitution stepper actually tried to route a call through the
(never-actually-shadowed) real imported `red`, which expects an
opaque Rune handle, not the raw Python int `4`.

createNoReassignmentValidator now also registers each `from X import
Y` binding, so a later def/assignment of the same name is rejected
exactly like any other reassignment. An import is never itself
rejected for colliding with an *earlier* import of the same name,
though: two imports binding the same name (even from different
modules) is real, separately-tested, intentional "last one wins"
behaviour (src/tests/py2js-from-import.test.ts), and the grammar
itself (python.ne) guarantees every import precedes every other
statement, so an import can never be the *later* half of a collision
with a def/assign -- only ever the earlier half, which is still
protecte... (continued)

4796 of 6000 branches covered (79.93%)

Branch coverage included in aggregate %.

21 of 21 new or added lines in 2 files covered. (100.0%)

10711 of 11986 relevant lines covered (89.36%)

164767.01 hits per line