Add deprecation warnings for `send()`, `transfer()`, ABI coder v1, contract comparisons, virtual modifiers and `memory-safe-assembly` comment #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.

docs/contracts/functions.rst

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

docs/contracts/inheritance.rst

docs/examples/blind-auction.rst

docs/types/value-types.rst

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?

I don't think so.

No, the comment was the backwards-compatible way to do it.

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.

matheusaaguiar

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

docs/control-structures.rst

docs/security-considerations.rst

clonker

some more comments :)

docs/contracts/functions.rst

docs/types/value-types.rst

docs/assembly.rst

docs/control-structures.rst

docs/security-considerations.rst

libsolidity/analysis/TypeChecker.cpp

clonker

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.

libsolidity/analysis/TypeChecker.cpp

test/libsolidity/syntaxTests/viewPureChecker/eof/builtin_functions.sol

matheusaaguiar · 2025-10-31T18:11:40Z

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.

clonker

Thanks for creating the tracking issue! Some more minor things I found in a final pass.

docs/contracts/functions.rst

docs/assembly.rst

libsolidity/analysis/TypeChecker.cpp

Changelog.md

matheusaaguiar · 2025-11-03T16:21:44Z

libsolidity/analysis/DocStringTagParser.cpp

 							2424_error,
 							_assembly.location(),
-							"Natspec memory safe annotation for inline assembly is deprecated and scheduled for removal in the next breaking version (0.9)."
+							"Natspec 'memory-safe-assembly' special comment for inline assembly is deprecated and scheduled for removal in the next breaking version (0.9)."


@clonker I've reworded the warning message here to be more in line with the suggestion you made for the changelog entry....what do you think?

Nice! Thinking about it again, it would be even better to mention that the assembly block annotation should be used instead. Like "Use the 'memory-safe' assembly block annotation instead". Or go with the whole sentence as in the docs.

clonker

I think in principle it is already good to go but we can still improve things a tiny bit so that the style is uniform, then there are no rough edges left. Then rebase, squash, merge :) for the future I think it would be beneficial to collect the introduced docstrings and/or warnings separately in a comment on the PR, then it's easier to check that the style is uniform. What do you think?

Documentation:

Note that send and transfer are deprecated and scheduled for removal in the next breaking version (0.9).
You are encouraged to use the :ref:call function <address_related> with an optionally provided maximum
amount of gas (default forwards all remaining gas) and an empty calldata parameter, e.g., call{value: amount}("").

Initially I suggested the "you are encouraged to" bit, but perhaps it's better to keep it brief and just say "Use the call function with an ...". I'll leave that up to you.

send/transfer is deprecated and scheduled for removal in the next breaking version (0.9).
You are encouraged to use the :ref:call function <address_call_functions> with an optionally provided maximum
amount of gas (default forwards all remaining gas) and an empty calldata parameter, e.g., call{value: amount}("").
Same as above.

virtual modifiers are deprecated and scheduled for removal in the next breaking version (0.9).

You might want to unify the style and add a "Note that" or remove it in all places.

The memory-safe-assembly special comment is deprecated and scheduled for
removal in the next breaking version (0.9).
For new code targeting recent compilers, prefer specifying the assembly block annotation.

Same as above, maybe instead of "prefer specifying" it should be "specify".

The ABI coder v1 is deprecated and scheduled for removal in the next breaking version (0.9).

Optionally you can expand and say "Use ABI coder v2 instead."

Warnings:

Natspec 'memory-safe-assembly' special comment for inline assembly is deprecated and scheduled for removal in the next breaking version (0.9).

Add a sentence what to use instead (ie the assembly block annotation).

ABI coder v1 is deprecated and scheduled for removal in the next breaking version (0.9).

Add a sentence what to use instead (ie ABI coder v2).

Virtual modifiers are deprecated and scheduled for removal in the next breaking version (0.9).

This is good. Although also here one can think about adding that there is no replacement (or is there?). I'll leave that up to you.

Comparison of variables of contract type is deprecated and scheduled for removal in the next breaking version (0.9). Instead, use an explicit cast to address type.

Just a small language / word order thing, I would write "Use an explicit cast to address type and compare the addresses instead."

'send/transfer' is deprecated and scheduled for removal in the next breaking version (0.9). It is encouraged to use 'call{{value: }}()' instead.

Same as the first point in the documentation, I'd unify it and make it more imperative, ie, "Use 'call{{value: }}()' instead".

matheusaaguiar · 2025-11-13T19:02:05Z

@clonker I think I have addressed all of your points.

clonker

I think it's good now! Just rebase, squash and then for all I'm concerned we can merge this.

cameel

I still wanted to make sure everything is fine here before we merge. Here's some quick feedback.

cameel · 2025-11-17T00:12:03Z

docs/assembly.rst

+    The ``memory-safe-assembly`` special comment is deprecated and scheduled for
+    removal in the next breaking version (0.9).


I'd not commit to a specific version here (or in error messages). Hopefully we do remove them in 0.9, but plans can change and these kinds of things sometimes stay in longer.

Suggested change

The ``memory-safe-assembly`` special comment is deprecated and scheduled for

removal in the next breaking version (0.9).

The ``memory-safe-assembly`` special comment is deprecated and scheduled for removal.

In fact this is actually incorrect in case of contract comparisons. These will not yet be removed in 0.9. Note that the feature is in the "Deprecate Only" column on the 0.9 planning board.

In case it wasn't clear, my comment was not only about this one instance. I see there are still quite a few error messages and notes in docs that explicitly mention 0.9.

cameel · 2025-11-17T00:12:52Z

docs/cheatsheet.rst

+.. warning::
+    ``send`` and ``transfer`` are deprecated and scheduled for removal in the next breaking version (0.9).
+    Use the :ref:`call function <address_call_functions>` with an optionally provided maximum amount of
+    gas (default forwards all remaining gas) and an empty calldata parameter, e.g., ``call{value: amount}("")``.


Suggested change

gas (default forwards all remaining gas) and an empty calldata parameter, e.g., ``call{value: amount}("")``.

gas (by default forwards all remaining gas) and an empty calldata parameter, e.g., ``call{value: amount}("")``.

Also, this is not exactly true due to the 63/64th gas rule.

Ah. Then this is already wrong, too: https://docs.soliditylang.org/en/v0.8.30/security-considerations.html#reentrancy - which is where I got the idea that it fwds all remaining gas in the first place.

I fixed it here and also in the Security Considerations section.

There are still quite a few places that say "forwards all remaining gas". Looks like you changed this only in some of them.

Ah. Then this is already wrong, too: https://docs.soliditylang.org/en/v0.8.30/security-considerations.html#reentrancy - which is where I got the idea that it fwds all remaining gas in the first place.

Interesting. I assumed we were more specific about it elsewhere in the docs. Now that I think about it, it's not incorrect, because that's what the compiler actually does - it sets the value to gas(). It's the EVM that ignores our exact value and caps it at 63/64th. Also, it only happens on tangerineWhistle and later EVMs. On older ones you actually do get all the gas forwarded. Maybe that part of the docs intentionally skipped all that complexity. Or maybe it was written before the rule was added.

Still, that's not what the user sees, so I think we should mention it in some way. The call in the end gets only 63/64th and the user in most cases does not even know or care who sets the limit. I'd rewrite the whole note like this:

`send()` and `transfer()` are deprecated and scheduled for removal. Simple ether transfers can still be performed using the [`call()`](...) function with empty payload, i.e., `call{value: <amount>}("")`. By default this forwards all the remaining gas, subject to additional limits imposed by some EVM versions (such as the [63/64th rule](https://eips.ethereum.org/EIPS/eip-150) introduced by `tangerineWhistle`). As with any external call, the `gas` call option can be used to set a lower limit. While it is possible to recreate the functionality by explicitly setting the limit to the value of the stipend (2300 gas), this value no longer holds its original meaning due to changing opcode costs. It is recommended to use different means to protect against reentrancy.

docs/control-structures.rst

docs/types/value-types.rst

libsolidity/analysis/DocStringTagParser.cpp

libsolidity/analysis/SyntaxChecker.cpp

libsolidity/analysis/TypeChecker.cpp

cameel · 2025-11-17T00:42:51Z

test/cmdlineTests/standard_model_checker_targets_assert_bmc/output.json

I don't think these SMTChecker tests require specifically transfer. We should update them to use call - we'll have to do that sooner or later anyway.

not part of the PR to change this, is it?

I started to work on those in #16291.

not part of the PR to change this, is it?

Could be either way. I'd change this here if I was doing the PR myself, but a separate PR is fine too.

cameel · 2025-11-17T00:44:24Z

test/externalTests/zeppelin.sh

+  .setAction(async (args, hre, runSuper) => {
+    const result = await runSuper(args);


Use 4-space indent.

I mean, for all lines, not just this single one :P

Changelog.md

cameel · 2025-11-25T19:51:54Z

libsolidity/analysis/DocStringTagParser.cpp

+						m_errorReporter.warning(
+							2424_error,
+							_assembly.location(),
+							"Natspec 'memory-safe-assembly' special comment for inline assembly is deprecated and "


If you do not quote memory-safe below, so I would not quote this either.

Suggested change

"Natspec 'memory-safe-assembly' special comment for inline assembly is deprecated and "

"Natspec memory-safe-assembly special comment for inline assembly is deprecated and "

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 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 force-pushed the deprecation_warnings branch 4 times, most recently from c203f66 to 3fb9ccd Compare October 29, 2025 12:44

matheusaaguiar commented Oct 29, 2025

View reviewed changes

docs/control-structures.rst Show resolved Hide resolved

docs/security-considerations.rst Show resolved Hide resolved

clonker reviewed Oct 30, 2025

View reviewed changes

matheusaaguiar force-pushed the deprecation_warnings branch from 88b472b to db310b6 Compare October 30, 2025 16:33

clonker requested changes Oct 31, 2025

View reviewed changes

libsolidity/analysis/TypeChecker.cpp Outdated Show resolved Hide resolved

test/libsolidity/syntaxTests/viewPureChecker/eof/builtin_functions.sol Show resolved Hide resolved

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

clonker reviewed Nov 1, 2025

View reviewed changes

matheusaaguiar force-pushed the deprecation_warnings branch 2 times, most recently from a260c59 to 069863a Compare November 3, 2025 14:34

matheusaaguiar commented Nov 3, 2025

View reviewed changes

clonker reviewed Nov 4, 2025

View reviewed changes

clonker previously approved these changes Nov 16, 2025

View reviewed changes

cameel requested changes Nov 17, 2025

View reviewed changes

matheusaaguiar dismissed clonker’s stale review via 0425e4e November 17, 2025 13:42

matheusaaguiar force-pushed the deprecation_warnings branch 2 times, most recently from d57fae4 to 7e86c8e Compare November 17, 2025 16:12

matheusaaguiar mentioned this pull request Nov 19, 2025

Replace transfer (deprecated) occurrences with call in smt tests #16291

Open

matheusaaguiar added 14 commits November 19, 2025 13:33

Natspect memory-safe annotation deprecation warning

2f71013

Update natspec warning tests

f7be6c7

ABI coder v1 deprecation warning

e4d28af

Update abi coder v1 tests

6043c4d

Contract type comparison deprecation warning

eb8c52b

Update contract type deprecation warning tests

f979b3b

Virtual modifier deprecation warning

505eecf

Update virtual modifier warning tests

e0aed72

Deprecation warning for send and transfer member functions

8de03c8

Update send/transfer warning tests

41e4075

zeppelin ext test workaround

7364fa3

Update docs

e997e0f

Changelog

03a49a1

fixup! Update tests

d97549f

matheusaaguiar force-pushed the deprecation_warnings branch from c55108b to d97549f Compare November 19, 2025 16:36

cameel reviewed Nov 25, 2025

View reviewed changes

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

		The ``memory-safe-assembly`` special comment is deprecated and scheduled for
		removal in the next breaking version (0.9).

	gas (default forwards all remaining gas) and an empty calldata parameter, e.g., ``call{value: amount}("")``.
	gas (by default forwards all remaining gas) and an empty calldata parameter, e.g., ``call{value: amount}("")``.

		.setAction(async (args, hre, runSuper) => {
		const result = await runSuper(args);

	"Natspec 'memory-safe-assembly' special comment for inline assembly is deprecated and "
	"Natspec memory-safe-assembly special comment for inline assembly is deprecated and "

Add deprecation warnings for send(), transfer(), ABI coder v1, contract comparisons, virtual modifiers and memory-safe-assembly comment #16174

Are you sure you want to change the base?

Add deprecation warnings for send(), transfer(), ABI coder v1, contract comparisons, virtual modifiers and memory-safe-assembly comment #16174

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!

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!

Uh oh!

Uh oh!

Uh oh!

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!

clonker commented Oct 28, 2025

Uh oh!

matheusaaguiar left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

clonker left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

clonker left a comment • 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!

Uh oh!

Uh oh!

matheusaaguiar commented Oct 31, 2025

Uh oh!

clonker left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

clonker Nov 4, 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!

clonker left a comment

Choose a reason for hiding this comment

Add deprecation warnings for `send()`, `transfer()`, ABI coder v1, contract comparisons, virtual modifiers and `memory-safe-assembly` comment #16174

Add deprecation warnings for `send()`, `transfer()`, ABI coder v1, contract comparisons, virtual modifiers and `memory-safe-assembly` comment #16174

matheusaaguiar commented Aug 19, 2025 •

edited

Loading

clonker left a comment •

edited

Loading

clonker Nov 4, 2025 •

edited

Loading

cameel Nov 17, 2025 •

edited

Loading

clonker Nov 17, 2025 •

edited

Loading

cameel Nov 25, 2025 •

edited

Loading