Merge remote-tracking branch 'origin/develop' into breaking

This commit is contained in:
chriseth
2020-11-03 14:05:14 +01:00
206 changed files with 1420 additions and 862 deletions
+1 -1
View File
@@ -132,7 +132,7 @@ Yul Optimizer
Together with the legacy bytecode optimizer, the :doc:`Yul <yul>` optimizer is now enabled by default when you call the compiler
with ``--optimize``. It can be disabled by calling the compiler with ``--no-optimize-yul``.
This mostly affects code that uses ABIEncoderV2.
This mostly affects code that uses ABI coder v2.
C API Changes
~~~~~~~~~~~~~
+2 -2
View File
@@ -589,8 +589,8 @@ As an example, the code
::
// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.4.19 <0.9.0;
pragma experimental ABIEncoderV2;
pragma solidity >0.7.4 <0.9.0;
pragma abicoder v2;
contract Test {
struct S { uint a; uint[] b; T[] c; }
+4 -4
View File
@@ -67,8 +67,8 @@ Function parameters can be used as any other local variable and they can also be
An :ref:`external function<external-function-calls>` cannot accept a
multi-dimensional array as an input
parameter. This functionality is possible if you enable the new
``ABIEncoderV2`` feature by adding ``pragma experimental ABIEncoderV2;`` to your source file.
parameter. This functionality is possible if you enable the ABI coder v2
by adding ``pragma abicoder v2;`` to your source file.
An :ref:`internal function<external-function-calls>` can accept a
multi-dimensional array without enabling the feature.
@@ -128,8 +128,8 @@ you must provide return values together with the return statement.
.. note::
You cannot return some types from non-internal functions, notably
multi-dimensional dynamic arrays and structs. If you enable the
new ``ABIEncoderV2`` feature by adding ``pragma experimental
ABIEncoderV2;`` to your source file then more types are available, but
ABI coder v2 by adding ``pragma abicoder v2;``
to your source file then more types are available, but
``mapping`` types are still limited to inside a single contract and you
cannot transfer them.
+1 -1
View File
@@ -239,7 +239,7 @@ For macOS builds, ensure that you have the latest version of
`Xcode installed <https://developer.apple.com/xcode/download/>`_.
This contains the `Clang C++ compiler <https://en.wikipedia.org/wiki/Clang>`_, the
`Xcode IDE <https://en.wikipedia.org/wiki/Xcode>`_ and other Apple development
tools which are required for building C++ applications on OS X.
tools that are required for building C++ applications on OS X.
If you are installing Xcode for the first time, or have just installed a new
version then you will need to agree to the license before you can do
command-line builds:
+38 -22
View File
@@ -88,6 +88,41 @@ these follow the same syntax used by `npm <https://docs.npmjs.com/misc/semver>`_
required by the pragma. If it does not match, the compiler issues
an error.
ABI Coder Pragma
----------------
By using ``pragma abicoder v1`` or ``pragma abicoder v2`` you can
select between the two implementations of the ABI encoder and decoder.
The new ABI coder (v2) is able to encode and decode arbitrarily nested
arrays and structs. It might produce less optimal code and has not
received as much testing as the old encoder, but is considered
non-experimental as of Solidity 0.6.0. You still have to explicitly
activate it using ``pragma abicoder v2;``. Since it will be
activated by default starting from Solidity 0.8.0, there is the option to select
the old coder using ``pragma abicoder v1;``.
The set of types supported by the new encoder is a strict superset of
the ones supported by the old one. Contracts that use it can interact with ones
that do not without limitations. The reverse is possible only as long as the
non-``abicoder v2`` contract does not try to make calls that would require
decoding types only supported by the new encoder. The compiler can detect this
and will issue an error. Simply enabling ``abicoder v2`` for your contract is
enough to make the error go away.
.. note::
This pragma applies to all the code defined in the file where it is activated,
regardless of where that code ends up eventually. This means that a contract
whose source file is selected to compile with ABI coder v1
can still contain code that uses the new encoder
by inheriting it from another contract. This is allowed if the new types are only
used internally and not in external function signatures.
.. note::
Up to Solidity 0.7.4, it was possible to select the ABI coder v2
by using ``pragma experimental ABIEncoderV2``, but it was not possible
to explicitly select coder v1 because it was the default.
.. index:: ! pragma, experimental
.. _experimental_pragma:
@@ -103,28 +138,9 @@ The following experimental pragmas are currently supported:
ABIEncoderV2
~~~~~~~~~~~~
The new ABI encoder is able to encode and decode arbitrarily nested
arrays and structs. It might produce less optimal code and has not
received as much testing as the old encoder, but is considered
non-experimental as of Solidity 0.6.0. You still have to explicitly
activate it using ``pragma experimental ABIEncoderV2;`` - we kept
the same pragma, even though it is not considered experimental
anymore.
The set of types supported by the new encoder is a strict superset of
the ones supported by the old one. Contracts that use it can interact with ones
that do not without limitations. The reverse is possible only as long as the
non-``ABIEncoderV2`` contract does not try to make calls that would require
decoding types only supported by the new encoder. The compiler can detect this
and will issue an error. Simply enabling ``ABIEncoderV2`` for your contract is
enough to make the error go away.
.. note::
This pragma applies to all the code defined in the file where it is activated,
regardless of where that code ends up eventually. This means that a contract
without the ``ABIEncoderV2`` pragma can still contain code that uses the new encoder
by inheriting it from another contract. This is allowed if the new types are only
used internally and not in external function signatures.
Because the ABI coder v2 is not considered experimental anymore,
it can be selected via ``pragma abicoder v2`` (please see above)
since Solidity 0.7.4.
.. _smt_checker:
+21 -7
View File
@@ -629,26 +629,32 @@ types.
// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.5.0;
pragma experimental ABIEncoderV2;
pragma experimental SMTChecker;
// This will report a warning
contract Aliasing
{
uint[] array;
uint[] array1;
uint[][] array2;
function f(
uint[] memory a,
uint[] memory b,
uint[][] memory c,
uint[] storage d
) internal view {
require(array[0] == 42);
require(a[0] == 2);
require(c[0][0] == 2);
require(d[0] == 2);
) internal {
array1[0] = 42;
a[0] = 2;
c[0][0] = 2;
b[0] = 1;
// Erasing knowledge about memory references should not
// erase knowledge about state variables.
assert(array[0] == 42);
assert(array1[0] == 42);
// However, an assignment to a storage reference will erase
// storage knowledge accordingly.
d[0] = 2;
// Fails as false positive because of the assignment above.
assert(array1[0] == 42);
// Fails because `a == b` is possible.
assert(a[0] == 2);
// Fails because `c[i] == b` is possible.
@@ -656,6 +662,14 @@ types.
assert(d[0] == 2);
assert(b[0] == 1);
}
function g(
uint[] memory a,
uint[] memory b,
uint[][] memory c,
uint x
) public {
f(a, b, c, array2[x]);
}
}
After the assignment to ``b[0]``, we need to clear knowledge about ``a`` since
+1 -1
View File
@@ -290,7 +290,7 @@ Array Members
.. note::
To use arrays of arrays in external (instead of public) functions, you need to
activate ABIEncoderV2.
activate ABI coder v2.
.. note::
In EVM versions before Byzantium, it was not possible to access
+4 -4
View File
@@ -231,7 +231,7 @@ Input Description
"cse": false,
// Optimize representation of literal numbers and strings in code.
"constantOptimizer": false,
// The new Yul optimizer. Mostly operates on the code of ABIEncoderV2
// The new Yul optimizer. Mostly operates on the code of ABI coder v2
// and inline assembly.
// It is activated together with the global optimizer setting
// and can be deactivated here.
@@ -321,8 +321,8 @@ Input Description
// evm.deployedBytecode.immutableReferences - Map from AST ids to bytecode ranges that reference immutables
// evm.methodIdentifiers - The list of function hashes
// evm.gasEstimates - Function gas estimates
// ewasm.wast - eWASM S-expressions format (not supported at the moment)
// ewasm.wasm - eWASM binary format (not supported at the moment)
// ewasm.wast - Ewasm in WebAssembly S-expressions format
// ewasm.wasm - Ewasm in WebAssembly binary format
//
// Note that using a using `evm`, `evm.bytecode`, `ewasm`, etc. will select every
// target part of that output. Additionally, `*` can be used as a wildcard to request everything.
@@ -486,7 +486,7 @@ Output Description
}
}
},
// eWASM related outputs
// Ewasm related outputs
"ewasm": {
// S-expressions format
"wast": "",
+2 -2
View File
@@ -9,7 +9,7 @@ Yul
Yul (previously also called JULIA or IULIA) is an intermediate language that can be
compiled to bytecode for different backends.
Support for EVM 1.0, EVM 1.5 and eWASM is planned, and it is designed to
Support for EVM 1.0, EVM 1.5 and Ewasm is planned, and it is designed to
be a usable common denominator of all three
platforms. It can already be used in stand-alone mode and
for "inline assembly" inside Solidity
@@ -1028,7 +1028,7 @@ An example Yul Object is shown below:
// executing code is the constructor code)
size := datasize("runtime")
offset := allocate(size)
// This will turn into a memory->memory copy for eWASM and
// This will turn into a memory->memory copy for Ewasm and
// a codecopy for EVM
datacopy(offset, dataoffset("runtime"), size)
return(offset, size)