Add various deprecation warnings #16174

matheusaaguiar · 2025-08-19T04:20:24Z

Partially solves #15795.
Deprecation warnings for:

comparison operators on contract type Reconsider operators on ContractType #11700.
.send and .transfer Remove .send and .transfer. #7455.
ABI coder v1 Remove ABIEncoderV1 #11323.
virtual modifiers Disallow virtual modifiers #12483.
/// @solidity memory-safe-assembly natspec comment.

cameel · 2025-08-19T17:47:04Z

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.

github-actions · 2025-09-26T12:06:39Z

This pull request is stale because it has been open for 14 days with no activity.
It will be closed in 7 days unless the stale label is removed.

github-actions · 2025-10-12T12:06:01Z

This pull request is stale because it has been open for 14 days with no activity.
It will be closed in 7 days unless the stale label is removed.

clonker · 2025-10-28T07:38:30Z

docs/contracts/functions.rst

    you have to implement a receive Ether function (using payable fallback functions for receiving Ether is
    not recommended, since the fallback is invoked and would not fail for interface confusions
    on the part of the sender).
+    Note that ``send`` and ``transfer`` are scheduled to be deprecated in the next breaking version (0.9).


Don't we deprecate them sooner, with this PR, and then with 0.9 (or another future breaking release) they are removed? Also I think this could be its own warning block. Perhaps even the first one.

I am not sure. I tried to find somewhere whether we define when it will be deprecated but couldn't locate anything yet.

Deprecated means it is available but it is encouraged to use something else (mostly because itll be removed in the future). So as soon as we merge the PR and have a release, it is deprecated. It was meant as a leading question. It should be phrased differently.

I guess I was using deprecation instead of removal. I will change the wording here to reflect that.

clonker · 2025-10-28T07:52:03Z

docs/contracts/functions.rst

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


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

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.

Yeah. It has to be done before we release though. :)

docs/contracts/functions.rst

clonker · 2025-10-28T07:59:08Z

docs/contracts/functions.rst

            // If someone sends Ether to that contract,
            // the transfer will fail, i.e. this returns false here.
+            // This will report a warning
            return testPayable.send(2 ether);


The new way of writing this without the gas limits would be this right?

(bool sent,) = address(test).call{value: 2 ether}(""); return sent;

That should be part of the warning.

docs/contracts/inheritance.rst

clonker · 2025-10-28T08:05:00Z

docs/contracts/inheritance.rst


 .. _modifier-overriding:

 Modifier Overriding


Maybe wouldn't hurt to clarify that this is deprecated already in the headline?

Suggested change

Modifier Overriding (deprecated)

docs/examples/blind-auction.rst

clonker · 2025-10-28T08:14:12Z

docs/types/value-types.rst

    (this can always be forced by the caller) and it also fails if the recipient runs out of gas. So in order
    to make safe Ether transfers, always check the return value of ``send``, use ``transfer`` or even better:
    use a pattern where the recipient withdraws the Ether.
+    Please, be aware that ``send`` will be deprecated in the next breaking version (0.9).


Could be a warning block

clonker · 2025-10-28T08:18:06Z

docs/assembly.rst

-backward-compatibility with older compiler versions, prefer using the dialect string.
+.. warning::
+    The ``memory-safe-assembly`` special comment will be deprecated in the next breaking version (0.9).
+    So, if you are not concerned with backward-compatibility with older compiler versions, prefer using the dialect string.


Out of curiosity, do we have a backwards-compatible way of handling this?

libsolidity/analysis/TypeChecker.cpp

clonker · 2025-10-28T08:37:16Z

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.

Co-authored-by: clonker <[email protected]>

matheusaaguiar force-pushed the deprecation_warnings branch 3 times, most recently from 3c00eb6 to f052fe2 Compare August 20, 2025 22:52

matheusaaguiar force-pushed the deprecation_warnings branch 2 times, most recently from 6d32b8c to 2531e30 Compare September 3, 2025 02:24

matheusaaguiar force-pushed the deprecation_warnings branch from 2531e30 to cb21835 Compare September 11, 2025 18:43

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 removed the stale The issue/PR was marked as stale because it has been open for too long. label Sep 27, 2025

matheusaaguiar force-pushed the deprecation_warnings branch from cb21835 to 0c67bef Compare September 27, 2025 12:55

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 removed the stale The issue/PR was marked as stale because it has been open for too long. label Oct 13, 2025

matheusaaguiar force-pushed the deprecation_warnings branch from 0c67bef to 2cf221d Compare October 13, 2025 17:21

matheusaaguiar requested a review from clonker October 27, 2025 14:52

matheusaaguiar added 14 commits October 27, 2025 11:53

Natspect memory-safe annotation deprecation warning

afbc1d7

Update natspec warning tests

d6c0008

ABI coder v1 deprecation warning

05491b6

Update abi coder v1 tests

982ab9f

Contract type comparison deprecation warning

7035b4c

Update contract type deprecation warning tests

1421dd4

Virtual modifier deprecation warning

ea62977

Update virtual modifier warning tests

54df0f1

Deprecation warning for send and transfer member functions

fa9fca2

Update send/transfer warning tests

0d9d8e9

Update smt tests

f54ef12

Update (tested) examples in docs

aeb700e

zeppelin ext test workaround

2521c12

Update docs with warnings

00e0006

Update cmdline tests

ab2e083

matheusaaguiar force-pushed the deprecation_warnings branch from 2cf221d to ab2e083 Compare October 27, 2025 14:53

clonker reviewed Oct 28, 2025

View reviewed changes

matheusaaguiar and others added 2 commits October 28, 2025 11:32

Update docs/contracts/functions.rst

6673863

Co-authored-by: clonker <[email protected]>

Apply suggestions from code review

e15585c

Co-authored-by: clonker <[email protected]>

Uh oh!

Add various deprecation warnings #16174

Are you sure you want to change the base?

Add various deprecation warnings #16174

Uh oh!

Conversation

matheusaaguiar commented Aug 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cameel commented Aug 19, 2025

Uh oh!

github-actions bot commented Sep 26, 2025

Uh oh!

github-actions bot commented Oct 12, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

clonker Oct 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

clonker commented Oct 28, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

matheusaaguiar commented Aug 19, 2025 •

edited

Loading

clonker Oct 28, 2025 •

edited

Loading