Skip to content

Conversation

@matheusaaguiar
Copy link
Collaborator

@matheusaaguiar matheusaaguiar commented Aug 19, 2025

Partially solves #15795.
Deprecation warnings for:

@cameel
Copy link
Collaborator

cameel commented Aug 19, 2025

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.

@matheusaaguiar matheusaaguiar force-pushed the deprecation_warnings branch 3 times, most recently from 3c00eb6 to f052fe2 Compare August 20, 2025 22:52
@matheusaaguiar matheusaaguiar force-pushed the deprecation_warnings branch 2 times, most recently from 6d32b8c to 2531e30 Compare September 3, 2025 02:24
@github-actions github-actions bot added the stale The issue/PR was marked as stale because it has been open for too long. label Sep 26, 2025
@matheusaaguiar matheusaaguiar removed the stale The issue/PR was marked as stale because it has been open for too long. label Sep 27, 2025
@github-actions github-actions bot added the stale The issue/PR was marked as stale because it has been open for too long. label Oct 12, 2025
@matheusaaguiar matheusaaguiar removed the stale The issue/PR was marked as stale because it has been open for too long. label Oct 13, 2025
Comment on lines 295 to 297
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>`
Copy link
Member

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

Copy link
Collaborator Author

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.

Copy link
Member

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. :)

@clonker
Copy link
Member

clonker commented Oct 28, 2025

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 of a deprecation you not only say that it is deprecated but also give a hint what to do instead. For example:

.. 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.

@matheusaaguiar matheusaaguiar force-pushed the deprecation_warnings branch 4 times, most recently from c203f66 to 3fb9ccd Compare October 29, 2025 12:44
Copy link
Collaborator Author

@matheusaaguiar matheusaaguiar left a 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).

Copy link
Member

@clonker clonker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some more comments :)

Copy link
Member

@clonker clonker left a 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.

@matheusaaguiar matheusaaguiar force-pushed the deprecation_warnings branch 2 times, most recently from b59a2b4 to 86da905 Compare October 31, 2025 17:44
@matheusaaguiar
Copy link
Collaborator Author

We should probably also start a docs/090-breaking-changes.rst and document this there.

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.

Copy link
Member

@clonker clonker left a 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.

@cameel cameel changed the title Add various deprecation warnings Add deprecation warnings for send(), transfer(), ABI coder v1, contract comparisons, virtual modifiers and memory-safe-assembly comment Nov 26, 2025
@cameel cameel changed the title Add deprecation warnings for send(), transfer(), ABI coder v1, contract comparisons, virtual modifiers and memory-safe-assembly comment Add deprecation warnings for send(), transfer(), ABI coder v1, contract comparisons, virtual modifiers and memory-safe-assembly comment Nov 26, 2025
@cameel cameel modified the milestones: 0.8.32, 0.8.31 Dec 2, 2025
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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What changed here?

Copy link
Collaborator Author

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.

Copy link
Collaborator Author

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.

@argotorg argotorg deleted a comment from github-actions bot Dec 2, 2025
@argotorg argotorg deleted a comment from github-actions bot Dec 2, 2025
@matheusaaguiar matheusaaguiar requested a review from cameel December 2, 2025 22:40
Comment on lines 326 to 364
.. 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``.
Copy link
Collaborator

@cameel cameel Dec 2, 2025

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.


Members of Address Types
------------------------
These members are explained in more detail in the section on :ref:`members of address <members-of-addresses>`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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
cameel previously approved these changes Dec 2, 2025
Copy link
Collaborator

@cameel cameel left a 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.

@matheusaaguiar
Copy link
Collaborator Author

@cameel I think everything is fixed now. I rebased and squashed the commits.
Please approve again.

@cameel cameel enabled auto-merge December 2, 2025 23:38
@cameel cameel merged commit ac77d12 into develop Dec 2, 2025
81 checks passed
@cameel cameel deleted the deprecation_warnings branch December 2, 2025 23:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants