fix: respect let binding shadowing in memory management

[scolsen]

Previously, we didn't account for shadowing in let bindings in our memory management routines. This led to rare situations in which multiple deleters might be added for a single variable name, for example:

(defn n [xs]
  (let [xs [1 2 3]
        n &xs]
    n))

The borrow checker would fail on this code since it would assign xs two deleters, one for the untyped argument and another for the let binding.

Instead, we now perform exclusive ownership transfer for the duration of the let scope--when a shadow is introduced, the previous deleters for that variable name are dropped until the end of the let scope, since we evaluate all instances of the shadowed name to the more local binding. At the end of the let scope, the original deleter is restored.

The code in the issue now produces:

The reference 'n' (depending on the variable 'xs') isn't alive at line 4, column 5 in '/Users/scottolsen/shadow.carp'. at /Users/scottolsen/shadow.carp:1:2.

Traceback:
  (defn n [xs] (let [xs [1 2 3] n (ref xs)] n)) at /Users/scottolsen/shadow.carp:1:1.
(load "../../shadow.carp") at REPL:1:1.

fixes #597

[scolsen]

As discussed in the issue, I originally thought we could just ignore type variables wrt to memory mgmt, but this doesn't work.

Luckily, we can use the state monad to selectively use deleters for shadows then restore the original deleters once we leave the let scope, which works quite nicely. An alternative would be to apply alpha renaming so that all bound variables are unique according to their scope, but this would be a significant effort.

[eriksvedang]

Nice!

Seems like the failing test is just due to an improved error message that needs adjusting in test/output/tes t/test-for-errors, right?

Alpha renaming shouldn't be super hard to do as a separate step, and it would make the memory management code cleaner, but also make error messages much worse (since they would sometimes refer to variable names that don't exist in the source.) Maybe if we un-alpha rename afterwards 😬 I'll try to think a little about if there's anything else we can do but if I can't come up with anything, I think this solution here makes sense.

Thanks a lot for solving the mystery of this bug, it had me completely stumped!

[scolsen]

Fixed!

[scolsen]

Thinking a bit more about it, I think this solution is the best one!

Before we merge, can you add a regression test for this bug (with a reference to the issue).

added!

[eriksvedang]

Lovely!