-
Notifications
You must be signed in to change notification settings - Fork 368
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
Slither fixes #300
Slither fixes #300
Conversation
1c5e692
to
7354d45
Compare
I don't think we should rename
In general I think we should have a very high bar for changing the name or signature of any existing properties/methods in an upgrade. |
Also, it would be great if changes like this could be broken up into separate PRs in the future - it is a lot easier to review small focused changes (e.g. a PR that adds |
It's mostly for developer confusion rather than user confusion (variable shadowing), but I do agree that we should have sufficient unit test coverage and stringent reviews so in practice it never actually causes a problem. I can revert the rename and keep the other changes. Sounds good? |
yeah, that sounds good |
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.
Look good.
To confirm my understanding the public
-> external
change will change how arguments are referenced in the generated code, but should have no effect on how the functions are invoked? So existing callers should be unaffected.
Oops accidentally re-requested a review. |
Existing callers should be unaffected, but I will add a test to be safe. |
Fixed issues detected by Slither
Issues found were minor:
The following issues can be safely ignored: