New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve resource tracking for optional binding #2044
Improve resource tracking for optional binding #2044
Conversation
Codecov Report
@@ Coverage Diff @@
## feature/stable-cadence #2044 +/- ##
==========================================================
- Coverage 77.70% 77.70% -0.01%
==========================================================
Files 304 304
Lines 63108 63125 +17
==========================================================
+ Hits 49037 49050 +13
- Misses 12360 12364 +4
Partials 1711 1711
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
Cadence Benchstat comparisonThis branch with compared with the base branch onflow:feature/stable-cadence commit 2d2a84e Collapsed results for better readability
|
Closes dapperlabs/cadence-private-issues#57
Port of dapperlabs/cadence-internal#104
Description
Optional-bindings, if-statements with variable declarations as a test, were implemented incorrectly.
The variable declaration was correctly only declared inside of the then-branch.
However, incorrectly, the value(s) were also only considered evaluated in the then branch. This produced incorrect resource-tracking errors, requiring users to unnecessarily invalidate the value in the else-branch, even though it should have been already definitely invalidated.
The variable declaration was initially only considered evaluated in the then-branch to support a special case: failable casing of resources (
r as? @R
). The failable cast was always definitely invalidating the casted variable, so it needed to be only occur in the then-branch. The proper way to handle this case is to always evaluate the variable declaration's value (as described above), but specifically handle the special construct of failable casting, and consider the casted variable invalidated in the then branch (the cast succeeded), and consider it not-invalidated in the else-branch (the cast failed).This is a breaking change, as it also now makes the unnecessary invalidation in the else-branch illegal.
master
branchFiles changed
in the Github PR explorer