fix: respect let binding shadowing in memory management #1413
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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:
```clojure
(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.
Fixes issue carp-lang#597
Since let scopes resolve to their bodies, we can report the body of the let as the xobj producing an error when a dead reference is returned.
|
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. |
|
Nice! Seems like the failing test is just due to an improved error message that needs adjusting in test/output/tes 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! |
|
Fixed! |
eriksvedang
approved these changes
Apr 11, 2022
Ensure we don't regress and fail to manage memory when let bindings shadow function argument names.
added! |
eriksvedang
approved these changes
Apr 11, 2022
|
Lovely! |
scolsen
added a commit
to scolsen/Carp
that referenced
this pull request
Apr 11, 2022
* fix: respect let binding shadowing in memory management
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:
```clojure
(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.
Fixes issue carp-lang#597
* refactor: improved dead reference error for let
Since let scopes resolve to their bodies, we can report the body of the
let as the xobj producing an error when a dead reference is returned.
* test: update error message for dead refs in let
* test: add regression test for issue carp-lang#597
Ensure we don't regress and fail to manage memory when let bindings
shadow function argument names.
eriksvedang
pushed a commit
that referenced
this pull request
Apr 13, 2022
* feat: register MAX and MIN macros for stdint types Adds MAX and MIN for each INT<N> type and MAX for each UINT<N> type. These are macros defined by stdint.h and are sometimes useful for bounds determinations and conversions and such. * feat: make MAX and MIN interfaces Since several numeric types define maximum and minimum values, it makes sense for these to be defined as interfaces. This commit also makes existing definitions of MAX and MIN for Carp's numeric types implement the interfaces. * fix: respect let binding shadowing in memory management (#1413) * fix: respect let binding shadowing in memory management 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: ```clojure (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. Fixes issue #597 * refactor: improved dead reference error for let Since let scopes resolve to their bodies, we can report the body of the let as the xobj producing an error when a dead reference is returned. * test: update error message for dead refs in let * test: add regression test for issue #597 Ensure we don't regress and fail to manage memory when let bindings shadow function argument names. * fix: respect symbol modes on interface concretization (#1415) * fix: respect symbol modes on interface concretization When concretizing interfaces (finding the appropriate implementation at a call site) we previously set the lookup mode of all such resolved symbols to CarpLand AFunction. This incorrectly overwrites the lookup mode of Externally registered types, causing them to emit incorrect C when the user specifies an override. We now preserve whatever lookup mode is assigned to the implementation the concretization resolves the interface to. This not only fixes the external override emission issue, but should be more correct in general. fixes #1414 * test: add regression test for issue #1414
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
The borrow checker would fail on this code since it would assign
xstwo 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:
fixes #597