-
-
Notifications
You must be signed in to change notification settings - Fork 799
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
feat[lang]: remove named reentrancy locks #3769
feat[lang]: remove named reentrancy locks #3769
Conversation
per GH issue 3760
Codecov ReportAttention:
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## master #3769 +/- ##
==========================================
+ Coverage 84.93% 85.02% +0.08%
==========================================
Files 92 92
Lines 13685 13700 +15
Branches 3074 3074
==========================================
+ Hits 11623 11648 +25
+ Misses 1572 1565 -7
+ Partials 490 487 -3 ☔ 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.
Question: I can declare variables as public
in Vyper and the compiler will generate a view
getter function on these functions. Example:
totalSupply: public(uint256)
Should it be possible via a kwarg
to set the global nonreentrant key there as well?
totalSupply: public(uint256, nonreentrant=True)
This brings up a great point around flipping reentrancy locks to being the default: how would a developer be able to allow the public getter generated to be accessible to a downstream caller contract, who may need to read some properties of the calling contract (maybe in a flash loan setting) |
hmm yea, why not. i was thinking about how to handle this for other decorators like |
What I did
implement #3760
How I did it
How to verify it
Commit message
Description for the changelog
Cute Animal Picture