Merge pull request #9862 from ethereum/develop

Merge develop into breaking
This commit is contained in:
chriseth
2020-09-23 12:22:32 +02:00
committed by GitHub
126 changed files with 2962 additions and 320 deletions
+6 -2
View File
@@ -105,8 +105,12 @@ otherwise, the ``value`` option would not be available.
parentheses at the end perform the actual call. So in this case, the
function is not called and the ``value`` and ``gas`` settings are lost.
Function calls cause exceptions if the called contract does not exist (in the
sense that the account does not contain code) or if the called contract itself
Due to the fact that the EVM considers a call to a non-existing contract to
always succeed, Solidity uses the ``extcodesize`` opcode to check that
the contract that is about to be called actually exists (it contains code)
and causes an exception if it does not.
Function calls also cause exceptions if the called contract itself
throws an exception or goes out of gas.
.. warning::
+20
View File
@@ -952,6 +952,26 @@ option.
See :ref:`Using the Commandline Compiler <commandline-compiler>` for details about the Solidity linker.
memoryguard
^^^^^^^^^^^
This function is available in the EVM dialect with objects. The caller of
``let ptr := memoryguard(size)`` (where ``size`` has to be a literal number)
promises that they only use memory in either the range ``[0, size)`` or the
unbounded range starting at ``ptr``.
Since the presence of a ``memoryguard`` call indicates that all memory access
adheres to this restriction, it allows the optimizer to perform additional
optimization steps, for example the stack limit evader, which attempts to move
stack variables that would otherwise be unreachable to memory.
The Yul optimizer promises to only use the memory range ``[size, ptr)`` for its purposes.
If the optimizer does not need to reserve any memory, it holds that ``ptr == size``.
``memoryguard`` can be called multiple times, but needs to have the same literal as argument
within one Yul subobject. If at least one ``memoryguard`` call is found in a subobject,
the additional optimiser steps will be run on it.
.. _yul-object: