mirror of
https://github.com/ethereum/solidity
synced 2023-10-03 13:03:40 +00:00
98 lines
5.2 KiB
ReStructuredText
98 lines
5.2 KiB
ReStructuredText
********************************
|
|
Solidity v0.8.0 Breaking Changes
|
|
********************************
|
|
|
|
This section highlights the main breaking changes introduced in Solidity
|
|
version 0.8.0.
|
|
For the full list check
|
|
`the release changelog <https://github.com/ethereum/solidity/releases/tag/v0.8.0>`_.
|
|
|
|
Silent Changes of the Semantics
|
|
===============================
|
|
|
|
This section lists changes where existing code changes its behaviour without
|
|
the compiler notifying you about it.
|
|
|
|
* Arithmetic operations revert on underflow and overflow. You can use ``unchecked { ... }`` to use
|
|
the previous wrapping behaviour.
|
|
|
|
Checks for overflow are very common, so we made them the default to increase readability of code,
|
|
even if it comes at a slight increase of gas costs.
|
|
|
|
* Exponentiation is right associative, i.e., the expression ``a**b**c`` is parsed as ``a**(b**c)``.
|
|
Before 0.8.0, it was parsed as ``(a**b)**c``.
|
|
|
|
This is the common way to parse the exponentiation operator.
|
|
|
|
* Failing assertions and other internal checks like division by zero or arithmetic overflow do
|
|
not use the invalid opcode but instead the revert opcode.
|
|
More specifically, they will use error data equal to a function call to ``Panic(uint256)`` with an error code specific
|
|
to the circumstances.
|
|
|
|
This will save gas on errors while it still allows static analysis tools to distinguish
|
|
these situations from a revert on invalid input, like a failing ``require``.
|
|
|
|
* If a byte array in storage is accessed whose length is encoded incorrectly, a panic is caused.
|
|
A contract cannot get into this situation unless inline assembly is used to modify the raw representation of storage byte arrays.
|
|
|
|
* If constants are used in array length expressions, previous versions of Solidity would use arbitrary precision
|
|
in all branches of the evaluation tree. Now, if constant variables are used as intermediate expressions,
|
|
their values will be properly rounded in the same way as when they are used in run-time expressions.
|
|
|
|
New Restrictions
|
|
================
|
|
|
|
* There are new restrictions related to explicit conversion of literals. The previous behaviour in
|
|
the following cases was likely ambiguous:
|
|
|
|
1. Explicit conversions from negative literals and literals larger than ``type(uint160).max`` to
|
|
``address`` are disallowed.
|
|
2. Explicit conversions between literals and an integer type ``T`` are only allowed if the literal
|
|
lies between ``type(T).min`` and ``type(T).max``. In particular, replace usages of ``uint(-1)``
|
|
with ``type(uint).max``.
|
|
3. Explicit conversions between literals and enums are only allowed if the literal can
|
|
represent a value in the enum.
|
|
|
|
* There are new restrictions on explicit type conversions. The conversion is only allowed when there
|
|
is at most one change in sign, width or type-category (``int``, ``address``, ``bytesNN``, etc.)
|
|
|
|
Let us use the notation ``T(S)`` to denote the explicit conversion ``T(x)``, where, ``T`` and
|
|
``S`` are types, and ``x`` is any arbitrary variable of type ``S``. An example of such a
|
|
disallowed conversion would be ``uint16(int8)`` since it changes both width (8 bits to 16 bits)
|
|
and sign (signed integer to unsigned integer). In order to do the conversion, one has to go
|
|
through an intermediate type. In the previous example, this would be ``uint16(uint8(int8))`` or
|
|
``uint16(int16(int8))``. Note that the two ways to convert will produce different results e.g.,
|
|
for ``-1``. The following are some examples of conversions that are disallowed by this rule.
|
|
|
|
- ``address(uint)`` and ``uint(address)``: converting both type-category and width. Replace this by
|
|
``address(uint160(uint))`` and ``uint(uint160(address))`` respectively.
|
|
- ``int80(bytes10)`` and ``bytes10(int80)``: converting both type-category and sign. Replace this by
|
|
``int80(uint80(bytes10))`` and ``bytes10(uint80(int80)`` respectively.
|
|
- ``Contract(uint)``: converting both type-category and width. Replace this by
|
|
``Contract(address(uint160(uint)))``.
|
|
|
|
These conversions were disallowed to avoid ambiguity. For example, in the expression ``uint16 x =
|
|
uint16(int8(-1))``, the value of ``x`` would depend on whether the sign or the width conversion
|
|
was applied first.
|
|
|
|
* Function call options can only be given once, i.e. ``c.f{gas: 10000}{value: 1}()`` is invalid and has to be changed to ``c.f{gas: 10000, value: 1}()``.
|
|
|
|
* The global functions ``log0``, ``log1``, ``log2``, ``log3`` and ``log4`` have been removed.
|
|
|
|
These are low-level functions that were largely unused. Their behaviour can be accessed from inline assembly.
|
|
|
|
* ``enum`` definitions cannot contain more than 256 members.
|
|
|
|
This will make it safe to assume that the underlying type in the ABI is always ``uint8``.
|
|
|
|
* Declarations with the name ``this``, ``super`` and ``_`` are disallowed, with the exception of
|
|
public functions and events.
|
|
|
|
* Remove support for the ``\b``, ``\f``, and ``\v`` escape sequences in code.
|
|
They can still be inserted via hexadecimal escapes, e.g. ``\x08``, ``\x0c``, and ``\x0b``, respectively.
|
|
|
|
Interface Changes
|
|
=================
|
|
|
|
* Changed output of ``--combined-json``. JSON fields ``abi``, ``devdoc``, ``userdoc`` and ``storage-layout`` are sub-objects now. Before 0.8.0 they used to be serialised as strings.
|