-
Notifications
You must be signed in to change notification settings - Fork 6.3k
Add deprecation warnings for send(), transfer(), ABI coder v1, contract comparisons, virtual modifiers and memory-safe-assembly comment
#16174
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
Conversation
|
Just a quick heads up: note that the issues you listed in the description should not be closed when this PR is merged. They're about feature removals and adding a warning is just an intermediate step, not a complete solution. |
3c00eb6 to
f052fe2
Compare
6d32b8c to
2531e30
Compare
2531e30 to
cb21835
Compare
cb21835 to
0c67bef
Compare
0c67bef to
2cf221d
Compare
2cf221d to
ab2e083
Compare
| call to the contract with empty calldata. This is the function that is executed | ||
| on plain Ether transfers (e.g. via ``.send()`` or ``.transfer()``). If no such | ||
| function exists, but a payable :ref:`fallback function <fallback-function>` |
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.
Perhaps not in this PR but I think we will have to go through the docs regarding send and transfer and see where we have to update them wrt best practices regarding send and transfer
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.
Yeah, I was thinking about this. We will need to update parts of the docs to reflect the deprecation of these functionalities.
I guess a separate PR for that would be better for organization purposes.
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.
Yeah. It has to be done before we release though. :)
|
Please go over the docs again, we will deprecate things before 0.9 and with 0.9 or a later version they will be removed. So "Note that XYZ will be deprecated in 0.9" should be "Note that XYZ are deprecated and scheduled for removal in 0.9". I find it a bit problematic to show deprecated code in the examples. This should be updated to be according to best practices. I am not sure if this PR is the right place for it, but if you find it's not, it should be done in a follow-up. Generally I'd have liked that alongside the .. warning::
The following patterns are deprecated and will be removed in v0.9:
- ``address.send()`` - Use ... instead
- ``address.transfer()`` - Use ...Also the code-emitted warnings have to be updated to reflect that things are deprecated now and will be removed in a future breaking release. Please present alternatives there (like for the send stuff to use call) and if possible it would be great to provide a link to the docs where this is described. Otherwise users are left stranded. Think what you would like to see if a compiler presents you with a deprecation warning. Implementation-wise it looks good. |
c203f66 to
3fb9ccd
Compare
matheusaaguiar
left a comment
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.
I have changed according to most of your suggestions @clonker. There are still some places where we need to properly rewrite or erase the docs to reflect the deprecation in the examples (send/transfer and virtual modifiers).
clonker
left a comment
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.
some more comments :)
88b472b to
db310b6
Compare
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.
Unfortunately still some things to do:
Here we have documentation of send and transfer but no mention that they're deprecated:
- docs/units-and-global-variables.rst (Members of Address Types section)
- docs/cheatsheet.rst (Address Related section)
Hope I didn't miss anything else in the documentation beyond these two. Wouldn't hurt to double-check.
Then there needs to be a changelog entry. We should probably also start a docs/090-breaking-changes.rst and document this there.
b59a2b4 to
86da905
Compare
I have started to do that, but will submit in a separate PR along other doc revisions, if you think it is ok. I created #16274 to track the work needed in order to update the docs for the breaking changes of v.0.9. |
clonker
left a comment
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.
Thanks for creating the tracking issue! Some more minor things I found in a final pass.
c053734 to
a260c59
Compare
d57fae4 to
7e86c8e
Compare
c55108b to
d97549f
Compare
send(), transfer(), ABI coder v1, contract comparisons, virtual modifiers and memory-safe-assembly comment
send(), transfer(), ABI coder v1, contract comparisons, virtual modifiers and memory-safe-assembly commentsend(), transfer(), ABI coder v1, contract comparisons, virtual modifiers and memory-safe-assembly comment
64e40cf to
beeeaae
Compare
| The caller always retains at least 1/64th of the gas in a call and thus | ||
| even if the called contract goes out of gas, the caller still | ||
| has some gas left. | ||
| has some gas left. |
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.
What changed here?
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.
No clue, maybe it needs a rebase.
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.
Or maybe it's a newline at the end of the file.
test/libsolidity/syntaxTests/viewPureChecker/eof/builtin_functions.sol
Outdated
Show resolved
Hide resolved
beeeaae to
d48aea9
Compare
test/libsolidity/syntaxTests/abiEncoder/conflicting_settings_reverse.sol
Outdated
Show resolved
Hide resolved
docs/types/value-types.rst
Outdated
| .. note:: | ||
| Prior to homestead, only a limited variant called ``callcode`` was available that did not provide access to the original ``msg.sender`` and ``msg.value`` values. This function was removed in version 0.5.0. | ||
| .. note:: | ||
| Prior to homestead, only a limited variant called ``callcode`` was available that did not provide access to the original ``msg.sender`` and ``msg.value`` values. This function was removed in version 0.5.0. | ||
|
|
||
| Since byzantium ``staticcall`` can be used as well. This is basically the same as ``call``, but will revert if the called function modifies the state in any way. | ||
| Since byzantium ``staticcall`` can be used as well. This is basically the same as ``call``, but will revert if the called function modifies the state in any way. | ||
|
|
||
| All three functions ``call``, ``delegatecall`` and ``staticcall`` are very low-level functions and should only be used as a *last resort* as they break the type-safety of Solidity. | ||
| All three functions ``call``, ``delegatecall`` and ``staticcall`` are very low-level functions and should only be used as a *last resort* as they break the type-safety of Solidity. | ||
|
|
||
| The ``gas`` option is available on all three methods, while the ``value`` option is only available | ||
| on ``call``. | ||
| The ``gas`` option is available on all three methods, while the ``value`` option is only available | ||
| on ``call``. |
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.
Just noticed that the indent here is too long. The text that was originally under the note is now inside it due to this.
docs/units-and-global-variables.rst
Outdated
|
|
||
| Members of Address Types | ||
| ------------------------ | ||
| These members are explained in more detail in the section on :ref:`members of address <members-of-addresses>` |
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.
| These members are explained in more detail in the section on :ref:`members of address <members-of-addresses>` | |
| These members are explained in more detail in the section on :ref:`members of address <members-of-addresses>`. |
cameel
left a comment
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.
Approving since this pretty much ready to go, just two minor tweaks remain.
…ory-safe-assembly, send and transfer functions, and virtual modifiers.
1d5585d to
b60f110
Compare
|
@cameel I think everything is fixed now. I rebased and squashed the commits. |
Partially solves #15795.
Deprecation warnings for:
.sendand.transferRemove .send and .transfer. #7455./// @solidity memory-safe-assemblynatspec comment.