-
-
Notifications
You must be signed in to change notification settings - Fork 795
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
refactor[tool]: refactor storage layout export #3789
refactor[tool]: refactor storage layout export #3789
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #3789 +/- ##
==========================================
- Coverage 90.82% 90.21% -0.62%
==========================================
Files 106 106
Lines 15309 15333 +24
Branches 3366 3378 +12
==========================================
- Hits 13904 13832 -72
- Misses 966 1036 +70
- Partials 439 465 +26 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this is a breaking change for tooling?
in theory, no. still ironing out some bugs though |
if not fn_t.nonreentrant: | ||
continue | ||
|
||
location = get_reentrancy_key_location() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
with overrides, non-reentrant key will be in storage, but the layout (-f
) will return that key in the transient_storage_layout
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right, so you're saying the output of -f layout
won't match the override file right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thats right
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
b9acf98, do you think this addresses it appropriately?
i think that overrides don't handle reentrancy lock properly: override file: {
"$.nonreentrant_key": {
"type": "uint256",
"slot": 1
}
} # main.vy
c: transient(uint256)
@external
@nonreentrant
def foo():
self.c = 0 and run with cancun:
outputs: {
"transient_storage_layout": {
"c": {
"type": "uint256",
"n_slots": 1,
"slot": 1
},
"$.nonreentrant_key": {
"type": "nonreentrant lock",
"slot": 1,
"n_slots": 1
}
}
} EDIT - adding also the corresponding IR
|
i added a sanity check that the storage layout roundtrips in b9acf98 |
function not exported, but # main.vy
import lib1
initializes: lib1
@deploy
def __init__():
lib1.counter = 99
# lib1.vy
counter: uint256
@external
@nonreentrant
def foo() -> uint256:
return self.counter Layout: {
"storage_layout": {
"lib1": {
"counter": {
"type": "uint256",
"n_slots": 1,
"slot": 0
}
}
},
"transient_storage_layout": {
"$.nonreentrant_key": {
"type": "nonreentrant lock",
"slot": 0,
"n_slots": 1
}
}
} EDIT: updated main.vy |
var_name unused
|
rather nothing, but reporting for completness lib1: uint256
@external
def foo():
pass {
"lib1": {
"slot": {
"slot": 20,
"type": "uint256",
"n_slots": 1
}
}
} panics w:
|
|
this part won't be fun with large arrays - in the future we should try to rewrite the logic to use interval intersections vyper/vyper/semantics/analysis/data_positions.py Lines 133 to 148 in 1042b90
EDIT: even for moderately-sized DynArrays (say |
dup of / tracked in #3966 |
What I did
refactor the storage layout export code
cc @ritzdorf @trocher
fixes #3996, #3517, #3989
How I did it
How to verify it
Commit message
Description for the changelog
Cute Animal Picture