Add various deprecation warnings

[matheusaaguiar]

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]

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]

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]

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]

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

[matheusaaguiar]

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.

[clonker]

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

[clonker]

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

[matheusaaguiar]

I don't think so.

[clonker]

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

[clonker]

some more comments :)

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

[matheusaaguiar]

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.

[matheusaaguiar]

@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?

[clonker]

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