aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
Diffstat
-rw-r--r--Changelog.md2
-rw-r--r--docs/050-breaking-changes.rst406
-rw-r--r--docs/assembly.rst95
-rw-r--r--docs/installing-solidity.rst2
-rw-r--r--docs/layout-of-source-files.rst52
-rw-r--r--docs/solidity-by-example.rst9
-rw-r--r--docs/solidity-in-depth.rst3
-rw-r--r--docs/structure-of-a-contract.rst3
-rw-r--r--docs/style-guide.rst22
-rw-r--r--docs/types.rst87
-rw-r--r--docs/units-and-global-variables.rst5
-rw-r--r--libevmasm/ExpressionClasses.cpp1
-rw-r--r--libevmasm/RuleList.h47
-rw-r--r--libevmasm/SimplificationRules.cpp21
-rw-r--r--libevmasm/SimplificationRules.h6
-rw-r--r--libjulia/optimiser/SimplificationRules.cpp7
-rw-r--r--libjulia/optimiser/SimplificationRules.h3
17 files changed, 679 insertions, 92 deletions
diff --git a/Changelog.md b/Changelog.md
index 2619801f..4e8b4ee3 100644
--- a/Changelog.md
+++ b/Changelog.md
@@ -102,6 +102,7 @@ Bugfixes:
* Commandline Interface: Correctly handle paths with backslashes on windows.
* Fix NatSpec json output for `@notice` and `@dev` tags on contract definitions.
* Optimizer: Correctly estimate gas costs of constants for special cases.
+ * Optimizer: Fix simplification rule initialization bug that appeared on some emscripten platforms.
* References Resolver: Do not crash on using ``_slot`` and ``_offset`` suffixes on their own.
* References Resolver: Enforce ``storage`` as data location for mappings.
* References Resolver: Properly handle invalid references used together with ``_slot`` and ``_offset``.
@@ -116,6 +117,7 @@ Bugfixes:
* Type Checker: Fix freeze for negative fixed-point literals very close to ``0``, such as ``-1e-100``.
* Type Checker: Dynamic types as key for public mappings return error instead of assertion fail.
* Type Checker: Fix internal error when array index value is too large.
+ * Type Checker: Fix internal error for array type conversions.
* Type System: Allow arbitrary exponents for literals with a mantissa of zero.
* Parser: Fix incorrect source location for nameless parameters.
diff --git a/docs/050-breaking-changes.rst b/docs/050-breaking-changes.rst
new file mode 100644
index 00000000..a28cc5ba
--- /dev/null
+++ b/docs/050-breaking-changes.rst
@@ -0,0 +1,406 @@
+********************************
+Solidity v0.5.0 Breaking Changes
+********************************
+
+This section highlights the main breaking changes introduced in Solidity
+version 0.5.0, along with the reasoning behind the changes and how to update
+affected code.
+For the full list check
+`the release changelog <https://github.com/ethereum/solidity/releases/tag/v0.5.0>`_.
+
+.. note::
+ Contracts compiled with Solidity v0.5.0 can still interface with contracts
+ and even libraries compiled with older versions without recompiling or
+ redeploying them. Changing the interfaces to include data locations and
+ visibility and mutability specifiers suffices.
+
+Semantic Only Changes
+=====================
+
+This section lists the changes that are semantic-only, thus potentially
+hiding new and different behavior in existing code.
+
+* Signed right shift now uses proper arithmetic shift, i.e. rounding towards
+ negative infinity, instead of rounding towards zero. Signed and unsigned
+ shift will have dedicated opcodes in Constantinople, and are emulated by
+ Solidity for the moment.
+
+* The ``continue`` statement in a ``do...while`` loop now jumps to the
+ condition, which is the common behavior in such cases. It used to jump to the
+ loop body. Thus, if the condition is false, the loop terminates.
+
+* The functions ``.call()``, ``.delegatecall()`` and ``.staticcall()`` do not
+ pad anymore when given a single ``bytes`` parameter.
+
+* Pure and view functions are now called using the opcode ``STATICCALL``
+ instead of ``CALL`` if the EVM version is Byzantium or later. This
+ disallows state changes on the EVM level.
+
+* The ABI encoder now properly pads byte arrays and strings from calldata
+ (``msg.data`` and external function parameters) when used in external
+ function calls and in ``abi.encode``. For unpadded encoding, use
+ ``abi.encodePacked``.
+
+* The ABI decoder reverts in the beginning of functions and in
+ ``abi.decode()`` if passed calldata is too short or points out of bounds.
+ Note that dirty higher order bits are still simply ignored.
+
+* Forward all available gas with external function calls starting from
+ tangerine whistle.
+
+Semantic and Syntactic Changes
+==============================
+
+This section highlights changes that affect syntax and semantics.
+
+* The functions ``.call()``, ``.delegatecall()`, ``staticcall()``,
+ ``keccak256()``, ``sha256()`` and ``ripemd160()`` now accept only a single
+ ``bytes`` argument. Moreover, the argument is not padded. This was changed to
+ make more explicit and clear how the arguments are concatenated. Change every
+ ``.call()`` (and family) to a ``.call("")`` and every ``.call(signature, a,
+ b, c)`` to use ``.call(abi.encodeWithSignature(signature, a, b, c))`` (the
+ last one only works for value types). Change every ``keccak256(a, b, c)`` to
+ ``keccak256(abi.encodePacked(a, b, c))``. Even though it is not a breaking
+ change, it is suggested that developers change
+ ``x.call(bytes4(keccak256("f(uint256)"), a, b)`` to
+ ``x.call(abi.encodeWithSignature("f(uint256)", a, b))``.
+
+* Functions ``.call()``, ``.delegatecall()`` and ``.staticcall()`` now return
+ ``(bool, bytes memory)`` to provide access to the return data. Change
+ ``bool success = otherContract.call("f")`` to ``(bool success, bytes memory
+ data) = otherContract.call("f")``.
+
+* Solidity now implements C99-style scoping rules for function local
+ variables, that is, variables can only be used after they have been
+ declared and only in the same or nested scopes. Variables declared in the
+ initialization block of a ``for`` loop are valid at any point inside the
+ loop.
+
+Explicitness Requirements
+=========================
+
+This section lists changes where the code now needs to be more explicit.
+For most of the topics the compiler will provide suggestions.
+
+* Explicit function visibility is now mandatory. Add ``public`` to every
+ function and constructor, and ``external`` to every fallback or interface
+ function that does not specify its visibility already.
+
+* Explicit data location for all variables of struct, array or mapping types is
+ now mandatory. This is also applied to function parameters and return
+ variables. For example, change ``uint[] x = m_x`` to ``uint[] storage x =
+ m_x``, and ``function f(uint[][] x)`` to ``function f(uint[][] memory x)``
+ where ``memory`` is the data location and might be replaced by ``storage`` or
+ ``calldata`` accordingly. Note that ``external`` functions require
+ parameters with a data location of ``calldata``.
+
+* Contract types do not include ``address`` members anymore in
+ order to separate the namespaces. Therefore, it is now necessary to
+ explicitly convert values of contract type to addresses before using an
+ ``address`` member. Example: if ``c`` is a contract, change
+ ``c.transfer(...)`` to ``address(c).transfer(...)``,
+ and ``c.balance`` to ``address(c).balance``.
+
+* The ``address`` type was split into ``address`` and ``address payable``,
+ where only ``address payable`` provides the ``transfer`` function. An
+ ``address payable`` can be directly converted to an ``address``, but the
+ other way around is not allowed. Converting ``address`` to ``address
+ payable`` is possible via conversion through ``uint160``. If ``c`` is
+ a contract, ``address(c)`` results in ``address payable`` if ``c`` has a
+ payable fallback function.
+
+* Conversions between ``bytesX`` and ``uintY`` of different size are now
+ disallowed due to ``bytesX`` padding on the right and ``uintY`` padding on
+ the left which may cause unexpected conversion results. The size must now be
+ adjusted within the type before the conversion. For example, you can convert
+ a ``bytes4`` (4 bytes) to a ``uint64`` (8 bytes) by first converting the
+ ``bytes4`` variable to ``bytes8`` and then to ``uint64``. You get the
+ opposite padding when converting through ``uint32``.
+
+* Using ``msg.value`` in non-payable functions (or introducing it via a
+ modifier) is disallowed as a security feature. Turn the function into
+ ``payable`` or create a new internal function for the program logic that
+ uses ``msg.value``.
+
+* For clarity reasons, the command line interface now requires ``-`` if the
+ standard input is used as source.
+
+Deprecated Elements
+===================
+
+This section lists changes that deprecate prior features or syntax. Note that
+many of these changes were already enabled in the experimental mode
+``v0.5.0``.
+
+Command Line and JSON Interfaces
+--------------------------------
+
+* The command line option ``--formal`` (used to generate Why3 output for
+ further formal verification) was deprecated and is now removed. A new
+ formal verification module, the SMTChecker, is enabled via ``pragma
+ experimental SMTChecker;``.
+
+* The command line option ``--julia`` was renamed to ``--yul`` due to the
+ renaming of the intermediate language ``Julia`` to ``Yul``.
+
+* The ``--clone-bin`` and ``--combined-json clone-bin`` command line options
+ were removed.
+
+* Remappings with empty prefix are disallowed.
+
+* The Json AST fields ``constant`` and ``payable`` were removed. The
+ information is now present in the ``stateMutability`` field.
+
+Constructors
+------------
+
+* Constructors must now be defined using the ``constructor`` keyword.
+
+* Calling base constructors without parentheses is now disallowed.
+
+* Specifying base constructor arguments multiple times in the same inheritance
+ hierarchy is now disallowed.
+
+* Calling a constructor with arguments but with wrong argument count is now
+ disallowed. If you only want to specify an inheritance relation without
+ giving arguments, do not provide parentheses at all.
+
+Functions
+---------
+
+* Function ``callcode`` is now disallowed (in favor of ``delegatecall``). It
+ is still possible to use it via inline assembly.
+
+* ``suicide`` is now disallowed (in favor of ``selfdestruct``).
+
+* ``sha3`` is now disallowed (in favor of ``keccak256``).
+
+* ``throw`` is now disallowed (in favor of ``revert``, ``require`` and
+ ``assert``).
+
+Conversions
+-----------
+
+* Explicit and implicit conversions from decimal literals to ``bytesXX`` types
+ is now disallowed.
+
+* Explicit and implicit conversions from hex literals to ``bytesXX`` types
+ of different size is now disallowed.
+
+Literals and Suffixes
+---------------------
+
+* The unit denomination ``years`` is now disallowed due to complications and
+ confusions about leap years.
+
+* Trailing dots that are not followed by a number are now disallowed.
+
+* Combining hex numbers with unit denominations (e.g. ``0x1e wei``) is now
+ disallowed.
+
+Variables
+---------
+
+* Declaring empty structs is now disallowed for clarity.
+
+* The ``var`` keyword is now disallowed to favor explicitness.
+
+* Assignments between tuples with different number of components is now
+ disallowed.
+
+* Values for constants that are not compile-time constants are disallowed.
+
+* Multi-variable declarations with mismatching number of values are now
+ disallowed.
+
+* Uninitialized storage variables are now disallowed.
+
+* Empty tuple components are now disallowed.
+
+* Detecting cyclic dependencies in variables and structs is limited in
+ recursion to 256.
+
+Syntax
+------
+
+* Using ``constant`` as function state mutability modifier is now disallowed.
+
+* Boolean expressions cannot use arithmetic operations.
+
+* The unary ``+`` operator is now disallowed.
+
+* Literals cannot anymore be used with ``abi.encodePacked`` without prior
+ conversion to an explicit type.
+
+* Empty return statements for functions with one or more return values are now
+ disallowed.
+
+* The "loose assembly" syntax is now disallowed entirely, that is, jump labels,
+ jumps and non-functional instructions cannot be used anymore. Use the new
+ ``while``, ``switch`` and ``if`` constructs instead.
+
+* Functions without implementation cannot use modifiers anymore.
+
+* Function types with named return values are now disallowed.
+
+* Single statement variable declarations inside if/while/for bodies that are
+ not blocks are now disallowed.
+
+* New keywords: ``calldata`` and ``constructor``.
+
+* New reserved keywords: ``alias``, ``apply``, ``auto``, ``copyof``,
+ ``define``, ``immutable``, ``implements``, ``macro``, ``mutable``,
+ ``override``, ``partial``, ``promise``, ``reference``, ``sealed``,
+ ``sizeof``, ``supports``, ``typedef`` and ``unchecked``.
+
+Example
+=======
+
+The following example shows a contract and its updated version for Solidity
+v0.5.0 with some of the changes listed in this section.
+
+Old version:
+
+::
+
+ // This will not compile
+ pragma solidity ^0.4.25;
+
+ contract OtherContract {
+ uint x;
+ function f(uint y) external {
+ x = y;
+ }
+ function() payable external {}
+ }
+
+ contract Old {
+ OtherContract other;
+ uint myNumber;
+
+ // Function mutability not provided, not an error.
+ function someInteger() internal returns (uint) { return 2; }
+
+ // Function visibility not provided, not an error.
+ // Function mutability not provided, not an error.
+ function f(uint x) returns (bytes) {
+ // Var is fine in this version.
+ var z = someInteger();
+ x += z;
+ // Throw is fine in this version.
+ if (x > 100)
+ throw;
+ bytes b = new bytes(x);
+ y = -3 >> 1;
+ // y == -1 (wrong, should be -2)
+ do {
+ x += 1;
+ if (x > 10) continue;
+ // 'Continue' causes an infinite loop.
+ } while (x < 11);
+ // Call returns only a Bool.
+ bool success = address(other).call("f");
+ if (!success)
+ revert();
+ else {
+ // Local variables could be declared after their use.
+ int y;
+ }
+ return b;
+ }
+
+ // No need for an explicit data location for 'arr'
+ function g(uint[] arr, bytes8 x, OtherContract otherContract) public {
+ otherContract.transfer(1 ether);
+
+ // Since uint32 (4 bytes) is smaller than bytes8 (8 bytes),
+ // the first 4 bytes of x will be lost. This might lead to
+ // unexpected behavior since bytesX are right padded.
+ uint32 y = uint32(x);
+ myNumber += y + msg.value;
+ }
+ }
+
+New version:
+
+::
+
+ pragma solidity >0.4.25;
+
+ contract OtherContract {
+ uint x;
+ function f(uint y) external {
+ x = y;
+ }
+ function() payable external {}
+ }
+
+ contract New {
+ OtherContract other;
+ uint myNumber;
+
+ // Function mutability must be specified.
+ function someInteger() internal pure returns (uint) { return 2; }
+
+ // Function visibility must be specified.
+ // Function mutability must be specified.
+ function f(uint x) public returns (bytes memory) {
+ // The type must now be explicitly given.
+ uint z = someInteger();
+ x += z;
+ // Throw is now disallowed.
+ require(x > 100);
+ int y = -3 >> 1;
+ // y == -2 (correct)
+ do {
+ x += 1;
+ if (x > 10) continue;
+ // 'Continue' jumps to the condition below.
+ } while (x < 11);
+
+ // Call returns (bool, bytes).
+ // Data location must be specified.
+ (bool success, bytes memory data) = address(other).call("f");
+ if (!success)
+ revert();
+ return data;
+ }
+
+ using address_make_payable for address;
+ // Data location for 'arr' must be specified
+ function g(uint[] memory arr, bytes8 x, OtherContract otherContract, address unknownContract) public payable {
+ // 'otherContract.transfer' is not provided.
+ // Since the code of 'OtherContract' is known and has the fallback
+ // function, address(otherContract) has type 'address payable'.
+ address(otherContract).transfer(1 ether);
+
+ // 'unknownContract.transfer' is not provided.
+ // 'address(unknownContract).transfer' is not provided
+ // since 'address(unknownContract)' is not 'address payable'.
+ // If the function takes an 'address' which you want to send
+ // funds to, you can convert it to 'address payable' via 'uint160'.
+ // Note: This is not recommended and the explicit type
+ // 'address payable' should be used whenever possible.
+ // To increase clarity, we suggest the use of a library for
+ // the conversion (provided after the contract in this example).
+ address payable addr = unknownContract.make_payable();
+ require(addr.send(1 ether));
+
+ // Since uint32 (4 bytes) is smaller than bytes8 (8 bytes),
+ // the conversion is not allowed.
+ // We need to convert to a common size first:
+ bytes4 x4 = bytes4(x); // Padding happens on the right
+ uint32 y = uint32(x4); // Conversion is consistent
+ // 'msg.value' cannot be used in a 'non-payable' function.
+ // We need to make the function payable
+ myNumber += y + msg.value;
+ }
+ }
+
+ // We can define a library for explicitly converting ``address``
+ // to ``address payable`` as a workaround.
+ library address_make_payable {
+ function make_payable(address x) internal pure returns (address payable) {
+ return address(uint160(x));
+ }
+ }
diff --git a/docs/assembly.rst b/docs/assembly.rst
index 91935293..90bfa1f1 100644
--- a/docs/assembly.rst
+++ b/docs/assembly.rst
@@ -4,22 +4,25 @@ Solidity Assembly
.. index:: ! assembly, ! asm, ! evmasm
-Solidity defines an assembly language that can also be used without Solidity.
-This assembly language can also be used as "inline assembly" inside Solidity
-source code. We start with describing how to use inline assembly and how it
-differs from standalone assembly and then specify assembly itself.
+Solidity defines an assembly language that you can use without Solidity and also
+as "inline assembly" inside Solidity source code. This guide starts with describing
+how to use inline assembly, how it differs from standalone assembly, and
+specifies assembly itself.
.. _inline-assembly:
Inline Assembly
===============
-For more fine-grained control especially in order to enhance the language by writing libraries,
-it is possible to interleave Solidity statements with inline assembly in a language close
-to the one of the virtual machine. Due to the fact that the EVM is a stack machine, it is
-often hard to address the correct stack slot and provide arguments to opcodes at the correct
-point on the stack. Solidity's inline assembly tries to facilitate that and other issues
-arising when writing manual assembly by the following features:
+You can interleave Solidity statements with inline assembly in a language close
+to the one of the virtual machine. This gives you more fine-grained control,
+especially when you are enhancing the language by writing libraries.
+
+As the EVM is a stack machine, it is often hard to address the correct stack slot
+and provide arguments to opcodes at the correct point on the stack. Solidity's inline
+assembly helps you do this, and with other issues that arise when writing manual assembly.
+
+Inline assembly has the following features:
* functional-style opcodes: ``mul(1, add(2, 3))``
* assembly-local variables: ``let x := add(2, 3) let y := mload(0x40) x := add(x, y)``
@@ -29,24 +32,38 @@ arising when writing manual assembly by the following features:
* switch statements: ``switch x case 0 { y := mul(x, 2) } default { y := 0 }``
* function calls: ``function f(x) -> y { switch x case 0 { y := 1 } default { y := mul(x, f(sub(x, 1))) } }``
-We now want to describe the inline assembly language in detail.
-
.. warning::
Inline assembly is a way to access the Ethereum Virtual Machine
- at a low level. This discards several important safety
- features of Solidity.
+ at a low level. This bypasses several important safety
+ features and checks of Solidity. You should only use it for
+ tasks that need it, and only if you are confident with using it.
-.. note::
- TODO: Write about how scoping rules of inline assembly are a bit different
- and the complications that arise when for example using internal functions
- of libraries. Furthermore, write about the symbols defined by the compiler.
+Syntax
+------
+
+Assembly parses comments, literals and identifiers in the same way as Solidity, so you can use the
+usual ``//`` and ``/* */`` comments. Inline assembly is marked by ``assembly { ... }`` and inside
+these curly braces, you can use the following (see the later sections for more details):
+
+ - literals, i.e. ``0x123``, ``42`` or ``"abc"`` (strings up to 32 characters)
+ - opcodes in functional style, e.g. ``add(1, mlod(0))``
+ - labels, e.g. ``name:``
+ - variable declarations, e.g. ``let x := 7``, ``let x := add(y, 3)`` or ``let x`` (initial value of empty (0) is assigned)
+ - identifiers (labels or assembly-local variables and externals if used as inline assembly), e.g. ``jump(name)``, ``3 x add``
+ - assignments (in "instruction style"), e.g. ``3 =: x``
+ - assignments in functional style, e.g. ``x := add(y, 3)``
+ - blocks where local variables are scoped inside, e.g. ``{ let x := 3 { let y := add(x, 1) } }``
+
+At the end of the ``assembly { ... }`` block, the stack must be balanced,
+unless you require it otherwise. If it is not balanced, the compiler generates
+a warning.
Example
-------
The following example provides library code to access the code of another contract and
-load it into a ``bytes`` variable. This is not possible at all with "plain Solidity" and the
-idea is that assembly libraries will be used to enhance the language in such ways.
+load it into a ``bytes`` variable. This is not possible with "plain Solidity" and the
+idea is that assembly libraries will be used to enhance the Solidity language.
.. code::
@@ -70,10 +87,8 @@ idea is that assembly libraries will be used to enhance the language in such way
}
}
-Inline assembly could also be beneficial in cases where the optimizer fails to produce
-efficient code. Please be aware that assembly is much more difficult to write because
-the compiler does not perform checks, so you should use it for complex things only if
-you really know what you are doing.
+Inline assembly is also beneficial in cases where the optimizer fails to produce
+efficient code, for example:
.. code::
@@ -125,22 +140,6 @@ you really know what you are doing.
}
-Syntax
-------
-
-Assembly parses comments, literals and identifiers exactly as Solidity, so you can use the
-usual ``//`` and ``/* */`` comments. Inline assembly is marked by ``assembly { ... }`` and inside
-these curly braces, the following can be used (see the later sections for more details)
-
- - literals, i.e. ``0x123``, ``42`` or ``"abc"`` (strings up to 32 characters)
- - opcodes in functional style, e.g. ``add(1, mlod(0))``
- - labels, e.g. ``name:``
- - variable declarations, e.g. ``let x := 7``, ``let x := add(y, 3)`` or ``let x`` (initial value of empty (0) is assigned)
- - identifiers (labels or assembly-local variables and externals if used as inline assembly), e.g. ``jump(name)``, ``3 x add``
- - assignments (in "instruction style"), e.g. ``3 =: x``
- - assignments in functional style, e.g. ``x := add(y, 3)``
- - blocks where local variables are scoped inside, e.g. ``{ let x := 3 { let y := add(x, 1) } }``
-
.. _opcodes:
Opcodes
@@ -368,17 +367,17 @@ Note that the order of arguments is reversed in functional-style as opposed to t
way. If you use functional-style, the first argument will end up on the stack top.
-Access to External Variables and Functions
-------------------------------------------
+Access to External Variables, Functions and Libraries
+-----------------------------------------------------
-Solidity variables and other identifiers can be accessed by simply using their name.
-For memory variables, this will push the address and not the value onto the
-stack. Storage variables are different: Values in storage might not occupy a
-full storage slot, so their "address" is composed of a slot and a byte-offset
+You can access Solidity variables and other identifiers by using their name.
+For variables stored in the memory data location, this pushes the address, and not the value
+onto the stack. Variables stored in the storage data location are different, as they might not
+occupy a full storage slot, so their "address" is composed of a slot and a byte-offset
inside that slot. To retrieve the slot pointed to by the variable ``x``, you
-used ``x_slot`` and to retrieve the byte-offset you used ``x_offset``.
+use ``x_slot``, and to retrieve the byte-offset you use ``x_offset``.
-In assignments (see below), we can even use local Solidity variables to assign to.
+Local Solidity variables are available for assignments, for example:
.. code::
diff --git a/docs/installing-solidity.rst b/docs/installing-solidity.rst
index 3332a83b..ba373b8f 100644
--- a/docs/installing-solidity.rst
+++ b/docs/installing-solidity.rst
@@ -303,6 +303,8 @@ CMake options
If you are interested what CMake options are available run ``cmake .. -LH``.
+.. _smt_solvers_build:
+
SMT Solvers
-----------
Solidity can be built against SMT solvers and will do so by default if
diff --git a/docs/layout-of-source-files.rst b/docs/layout-of-source-files.rst
index b88e7e45..11f85aac 100644
--- a/docs/layout-of-source-files.rst
+++ b/docs/layout-of-source-files.rst
@@ -2,15 +2,23 @@
Layout of a Solidity Source File
********************************
-Source files can contain an arbitrary number of contract definitions, include directives
-and pragma directives.
+Source files can contain an arbitrary number of
+:ref:`contract definitions<contract_structure>`, import_ directives
+and :ref:`pragma directives<pragma>`.
+
+.. index:: ! pragma
+
+.. _pragma:
+
+Pragmas
+=======
.. index:: ! pragma, version
.. _version_pragma:
Version Pragma
-==============
+--------------
Source files can (and should) be annotated with a so-called version pragma to reject
being compiled with future compiler versions that might introduce incompatible
@@ -35,6 +43,44 @@ the exact version of the compiler, so that bugfix releases are still possible.
It is possible to specify much more complex rules for the compiler version,
the expression follows those used by `npm <https://docs.npmjs.com/misc/semver>`_.
+.. index:: ! pragma, experimental
+
+.. _experimental_pragma:
+
+Experimental Pragma
+-------------------
+
+The second pragma is the experimental pragma. It can be used to enable
+features of the compiler or language that are not yet enabled by default.
+The following experimental pragmas are currently supported:
+
+
+ABIEncoderV2
+~~~~~~~~~~~~
+
+The new ABI encoder is able to encode and decode arbitrarily nested
+arrays and structs. It produces less optimal code (the optimizer
+for this part of the code is still under development) and has not
+received as much testing as the old encoder. You can activate it
+using ``pragma experimental ABIEncoderV2;``.
+
+SMTChecker
+~~~~~~~~~~
+
+This component has to be enabled when the Solidity compiler is built
+and therefore it is not available in all Solidity binaries.
+The :ref:`build instructions<smt_solvers_build>` explain how to activate this option.
+It is activated for the Ubuntu PPA releases in most versions,
+but not for solc-js, the Docker images, Windows binaries or the
+statically-built Linux binaries.
+
+If you use
+``pragma experimental SMTChecker;``, then you get additional
+safety warnings which are obtained by querying an SMT solver.
+The component does not yet support all features of the Solidity language
+and likely outputs many warnings. In case it reports unsupported
+features, the analysis may not be fully sound.
+
.. index:: source file, ! import
.. _import:
diff --git a/docs/solidity-by-example.rst b/docs/solidity-by-example.rst
index 0b183ca5..d01886f8 100644
--- a/docs/solidity-by-example.rst
+++ b/docs/solidity-by-example.rst
@@ -220,7 +220,7 @@ bid. If the highest bid is raised, the previously
highest bidder gets her money back.
After the end of the bidding period, the
contract has to be called manually for the
-beneficiary to receive his money - contracts cannot
+beneficiary to receive their money - contracts cannot
activate themselves.
::
@@ -241,10 +241,11 @@ activate themselves.
// Allowed withdrawals of previous bids
mapping(address => uint) pendingReturns;
- // Set to true at the end, disallows any change
+ // Set to true at the end, disallows any change.
+ // By defaul initialized to `false`.
bool ended;
- // Events that will be fired on changes.
+ // Events that will be emitted on changes.
event HighestBidIncreased(address bidder, uint amount);
event AuctionEnded(address winner, uint amount);
@@ -372,7 +373,7 @@ is the same as the one provided during the bidding period.
Another challenge is how to make the auction
**binding and blind** at the same time: The only way to
prevent the bidder from just not sending the money
-after he won the auction is to make her send it
+after they won the auction is to make her send it
together with the bid. Since value transfers cannot
be blinded in Ethereum, anyone can see the value.
diff --git a/docs/solidity-in-depth.rst b/docs/solidity-in-depth.rst
index b6217b47..ddfddb77 100644
--- a/docs/solidity-in-depth.rst
+++ b/docs/solidity-in-depth.rst
@@ -4,7 +4,7 @@ Solidity in Depth
This section should provide you with all you need to know about Solidity.
If something is missing here, please contact us on
-`Gitter <https://gitter.im/ethereum/solidity>`_ or make a pull request on
+`Gitter <https://gitter.im/ethereum/solidity>`_ or create a pull request on
`Github <https://github.com/ethereum/solidity/pulls>`_.
.. toctree::
@@ -18,3 +18,4 @@ If something is missing here, please contact us on
contracts.rst
assembly.rst
miscellaneous.rst
+ 050-breaking-changes.rst
diff --git a/docs/structure-of-a-contract.rst b/docs/structure-of-a-contract.rst
index 1b4a6c55..d8bc51b8 100644
--- a/docs/structure-of-a-contract.rst
+++ b/docs/structure-of-a-contract.rst
@@ -21,7 +21,8 @@ which serves to provide a quick overview.
State Variables
===============
-State variables are values which are permanently stored in contract storage.
+State variables are variables whose values are permanently stored in contract
+storage.
::
diff --git a/docs/style-guide.rst b/docs/style-guide.rst
index d2de5287..511236b9 100644
--- a/docs/style-guide.rst
+++ b/docs/style-guide.rst
@@ -874,6 +874,28 @@ No::
x = y+z;
x +=1;
+***************
+Order of Layout
+***************
+
+Layout contract elements in the following order:
+
+1. Import statements
+2. Interfaces
+3. Libraries
+4. Contracts
+
+Inside each contract, library or interface, use the following order:
+
+1. Type declarations
+2. State variables
+3. Events
+4. Functions
+
+.. note::
+
+ It might be clearer to declare types close to their use in events or state
+ variables.
******************
Naming Conventions
diff --git a/docs/types.rst b/docs/types.rst
index eaec8ad5..de384e2f 100644
--- a/docs/types.rst
+++ b/docs/types.rst
@@ -50,14 +50,25 @@ Operators:
* Comparisons: ``<=``, ``<``, ``==``, ``!=``, ``>=``, ``>`` (evaluate to ``bool``)
* Bit operators: ``&``, ``|``, ``^`` (bitwise exclusive or), ``~`` (bitwise negation)
-* Arithmetic operators: ``+``, ``-``, unary ``-``, unary ``+``, ``*``, ``/``, ``%`` (remainder), ``**`` (exponentiation), ``<<`` (left shift), ``>>`` (right shift)
+* Shift operators: ``<<`` (left shift), ``>>`` (right shift)
+* Arithmetic operators: ``+``, ``-``, unary ``-``, ``*``, ``/``, ``%`` (remainder), ``**`` (exponentiation)
-Division always truncates (it is just compiled to the ``DIV`` opcode of the EVM), but it does not truncate if both
-operators are :ref:`literals<rational_literals>` (or literal expressions).
-Division by zero and modulus with zero throws a runtime exception.
+Comparisons
+^^^^^^^^^^^
+
+The value of a comparison is the one obtained by comparing the integer value.
+
+Bit operations
+^^^^^^^^^^^^^^
+
+Bit operations are performed on the two's complement representation of the number.
+This means that, for example ``~int256(0) == int256(-1)``.
+
+Shifts
+^^^^^^
-The result of a shift operation is the type of the left operand. The
+The result of a shift operation has the type of the left operand. The
expression ``x << y`` is equivalent to ``x * 2**y``, and, for positive integers,
``x >> y`` is equivalent to ``x / 2**y``. For negative ``x``, ``x >> y``
is equivalent to dividing by a power of ``2`` while rounding down (towards negative infinity).
@@ -67,6 +78,34 @@ Shifting by a negative amount throws a runtime exception.
Before version ``0.5.0`` a right shift ``x >> y`` for negative ``x`` was equivalent to ``x / 2**y``,
i.e. right shifts used rounding towards zero instead of rounding towards negative infinity.
+Addition, Subtraction and Multiplication
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Addition, subtraction and multiplication have the usual semantics.
+They wrap in two's complement notation, meaning that
+for example ``uint256(0) - uint256(1) == 2**256 - 1``. You have to take these overflows
+into account when designing safe smart contracts.
+
+Division and Modulus
+^^^^^^^^^^^^^^^^^^^^
+
+Since the type of the result of an operation is always the type of one of
+the operands, division on integers always results in an integer.
+In Solidity, division rounds towards zero. This mean that ``int256(-5) / int256(2) == int256(-2)``.
+
+Note that in contrast, division on :ref:`literals<rational_literals>` results in fractional values
+of arbitrary precision.
+
+Division by zero and modulus with zero throws a runtime exception.
+
+Exponentiation
+^^^^^^^^^^^^^^
+
+Exponentiation is only available for unsigned types. Please take care that the types
+you are using are large enough to hold the result and prepare for potential wrapping behaviour.
+
+Note that ``0**0`` is defined by the EVM as ``1``.
+
.. index:: ! ufixed, ! fixed, ! fixed point number
Fixed Point Numbers
@@ -932,26 +971,30 @@ assigning it to a local variable, as in
Mappings
========
-Mapping types are declared as ``mapping(_KeyType => _ValueType)``.
-Here ``_KeyType`` can be almost any type except for a mapping, a dynamically sized array, a contract, a function, an enum and a struct.
-``_ValueType`` can actually be any type, including mappings.
+You declare mapping types with the syntax ``mapping(_KeyType => _ValueType)``.
+The ``_KeyType`` can be any elementary type. This means it can be any of
+the built-in value types plus ``bytes`` and ``string``. User-defined
+or complex types like contract types, enums, mappings, structs and any array type
+apart from ``bytes`` and ``string`` are not allowed.
+``_ValueType`` can be any type, including mappings.
-Mappings can be seen as `hash tables <https://en.wikipedia.org/wiki/Hash_table>`_ which are virtually initialized such that
-every possible key exists and is mapped to a value whose byte-representation is
-all zeros: a type's :ref:`default value <default-value>`. The similarity ends here, though: The key data is not actually stored
-in a mapping, only its ``keccak256`` hash used to look up the value.
+You can think of mappings as `hash tables <https://en.wikipedia.org/wiki/Hash_table>`_, which are virtually initialized
+such that every possible key exists and is mapped to a value whose
+byte-representation is all zeros, a type's :ref:`default value <default-value>`. The similarity ends there, the key data is not stored in a
+mapping, only its ``keccak256`` hash is used to look up the value.
-Because of this, mappings do not have a length or a concept of a key or value being "set".
+Because of this, mappings do not have a length or a concept of a key or
+value being set.
-Mappings are only allowed for state variables (or as storage reference types
+Mappings are **only** allowed for state variables (or as storage reference types
in internal functions).
-It is possible to mark mappings ``public`` and have Solidity create a :ref:`getter <visibility-and-getters>`.
-The ``_KeyType`` will become a required parameter for the getter and it will
-return ``_ValueType``.
-
-The ``_ValueType`` can be a mapping too. The getter will have one parameter
-for each ``_KeyType``, recursively.
+You can mark variables of mapping type as ``public`` and Solidity creates a
+:ref:`getter <visibility-and-getters>` for you. The ``_KeyType`` becomes a
+parameter for the getter. If ``_ValueType`` is a value type or a struct,
+the getter returns ``_ValueType``.
+If ``_ValueType`` is an array or a mapping, the getter has one parameter for
+each ``_KeyType``, recursively. For example with a mapping:
::
@@ -975,8 +1018,8 @@ for each ``_KeyType``, recursively.
.. note::
- Mappings are not iterable, but it is possible to implement a data structure on top of them.
- For an example, see `iterable mapping <https://github.com/ethereum/dapp-bin/blob/master/library/iterable_mapping.sol>`_.
+ Mappings are not iterable, but it is possible to implement a data structure
+ on top of them. For an example, see `iterable mapping <https://github.com/ethereum/dapp-bin/blob/master/library/iterable_mapping.sol>`_.
.. index:: assignment, ! delete, lvalue
diff --git a/docs/units-and-global-variables.rst b/docs/units-and-global-variables.rst
index 2e1b90a0..d6ef393e 100644
--- a/docs/units-and-global-variables.rst
+++ b/docs/units-and-global-variables.rst
@@ -151,6 +151,11 @@ Mathematical and Cryptographic Functions
recover the address associated with the public key from elliptic curve signature or return zero on error
(`example usage <https://ethereum.stackexchange.com/q/1777/222>`_)
+.. note::
+ Function ``ecrecover`` returns an ``address``, and not an ``address
+ payable``. See :ref:`address payable<address>` for conversion, in case you need
+ to transfer funds to the recovered address.
+
It might be that you run into Out-of-Gas for ``sha256``, ``ripemd160`` or ``ecrecover`` on a *private blockchain*. The reason for this is that those are implemented as so-called precompiled contracts and these contracts only really exist after they received the first message (although their contract code is hardcoded). Messages to non-existing contracts are more expensive and thus the execution runs into an Out-of-Gas error. A workaround for this problem is to first send e.g. 1 Wei to each of the contracts before you use them in your actual contracts. This is not an issue on the official or test net.
.. index:: balance, send, transfer, call, callcode, delegatecall, staticcall
diff --git a/libevmasm/ExpressionClasses.cpp b/libevmasm/ExpressionClasses.cpp
index 69b33ec5..42a1819a 100644
--- a/libevmasm/ExpressionClasses.cpp
+++ b/libevmasm/ExpressionClasses.cpp
@@ -184,6 +184,7 @@ string ExpressionClasses::fullDAGToString(ExpressionClasses::Id _id) const
ExpressionClasses::Id ExpressionClasses::tryToSimplify(Expression const& _expr)
{
static Rules rules;
+ assertThrow(rules.isInitialized(), OptimizerException, "Rule list not properly initialized.");
if (
!_expr.item ||
diff --git a/libevmasm/RuleList.h b/libevmasm/RuleList.h
index 0573856b..874a8929 100644
--- a/libevmasm/RuleList.h
+++ b/libevmasm/RuleList.h
@@ -44,12 +44,11 @@ template <class S> S modWorkaround(S const& _a, S const& _b)
return (S)(bigint(_a) % bigint(_b));
}
-/// @returns a list of simplification rules given certain match placeholders.
-/// A, B and C should represent constants, X and Y arbitrary expressions.
-/// The simplifications should never change the order of evaluation of
-/// arbitrary operations.
+// This part of simplificationRuleList below was split out to prevent
+// stack overflows in the JavaScript optimizer for emscripten builds
+// that affected certain browser versions.
template <class Pattern>
-std::vector<SimplificationRule<Pattern>> simplificationRuleList(
+std::vector<SimplificationRule<Pattern>> simplificationRuleListPart1(
Pattern A,
Pattern B,
Pattern C,
@@ -57,8 +56,7 @@ std::vector<SimplificationRule<Pattern>> simplificationRuleList(
Pattern Y
)
{
- std::vector<SimplificationRule<Pattern>> rules;
- rules += std::vector<SimplificationRule<Pattern>>{
+ return std::vector<SimplificationRule<Pattern>> {
// arithmetic on constants
{{Instruction::ADD, {A, B}}, [=]{ return A.d() + B.d(); }, false},
{{Instruction::MUL, {A, B}}, [=]{ return A.d() * B.d(); }, false},
@@ -162,6 +160,22 @@ std::vector<SimplificationRule<Pattern>> simplificationRuleList(
{{Instruction::OR, {X, {Instruction::NOT, {X}}}}, [=]{ return ~u256(0); }, true},
{{Instruction::OR, {{Instruction::NOT, {X}}, X}}, [=]{ return ~u256(0); }, true},
};
+}
+
+
+// This part of simplificationRuleList below was split out to prevent
+// stack overflows in the JavaScript optimizer for emscripten builds
+// that affected certain browser versions.
+template <class Pattern>
+std::vector<SimplificationRule<Pattern>> simplificationRuleListPart2(
+ Pattern A,
+ Pattern B,
+ Pattern,
+ Pattern X,
+ Pattern Y
+)
+{
+ std::vector<SimplificationRule<Pattern>> rules;
// Replace MOD X, <power-of-two> with AND X, <power-of-two> - 1
for (size_t i = 0; i < 256; ++i)
@@ -292,5 +306,24 @@ std::vector<SimplificationRule<Pattern>> simplificationRuleList(
return rules;
}
+/// @returns a list of simplification rules given certain match placeholders.
+/// A, B and C should represent constants, X and Y arbitrary expressions.
+/// The simplifications should never change the order of evaluation of
+/// arbitrary operations.
+template <class Pattern>
+std::vector<SimplificationRule<Pattern>> simplificationRuleList(
+ Pattern A,
+ Pattern B,
+ Pattern C,
+ Pattern X,
+ Pattern Y
+)
+{
+ std::vector<SimplificationRule<Pattern>> rules;
+ rules += simplificationRuleListPart1(A, B, C, X, Y);
+ rules += simplificationRuleListPart2(A, B, C, X, Y);
+ return rules;
+}
+
}
}
diff --git a/libevmasm/SimplificationRules.cpp b/libevmasm/SimplificationRules.cpp
index 504dbc24..ba13a611 100644
--- a/libevmasm/SimplificationRules.cpp
+++ b/libevmasm/SimplificationRules.cpp
@@ -21,16 +21,19 @@
* Container for equivalence classes of expressions for use in common subexpression elimination.
*/
+#include <libevmasm/SimplificationRules.h>
+
#include <libevmasm/ExpressionClasses.h>
-#include <utility>
-#include <functional>
-#include <boost/range/adaptor/reversed.hpp>
-#include <boost/noncopyable.hpp>
#include <libevmasm/Assembly.h>
#include <libevmasm/CommonSubexpressionEliminator.h>
-#include <libevmasm/SimplificationRules.h>
-
#include <libevmasm/RuleList.h>
+#include <libdevcore/Assertions.h>
+
+#include <boost/range/adaptor/reversed.hpp>
+#include <boost/noncopyable.hpp>
+
+#include <utility>
+#include <functional>
using namespace std;
using namespace dev;
@@ -54,6 +57,11 @@ SimplificationRule<Pattern> const* Rules::findFirstMatch(
return nullptr;
}
+bool Rules::isInitialized() const
+{
+ return !m_rules[byte(Instruction::ADD)].empty();
+}
+
void Rules::addRules(std::vector<SimplificationRule<Pattern>> const& _rules)
{
for (auto const& r: _rules)
@@ -82,6 +90,7 @@ Rules::Rules()
Y.setMatchGroup(5, m_matchGroups);
addRules(simplificationRuleList(A, B, C, X, Y));
+ assertThrow(isInitialized(), OptimizerException, "Rule list not properly initialized.");
}
Pattern::Pattern(Instruction _instruction, std::vector<Pattern> const& _arguments):
diff --git a/libevmasm/SimplificationRules.h b/libevmasm/SimplificationRules.h
index 53f7e595..fbe5a2b0 100644
--- a/libevmasm/SimplificationRules.h
+++ b/libevmasm/SimplificationRules.h
@@ -26,6 +26,8 @@
#include <libevmasm/ExpressionClasses.h>
#include <libevmasm/SimplificationRule.h>
+#include <boost/noncopyable.hpp>
+
#include <functional>
#include <vector>
@@ -53,6 +55,10 @@ public:
ExpressionClasses const& _classes
);
+ /// Checks whether the rulelist is non-empty. This is usually enforced
+ /// by the constructor, but we had some issues with static initialization.
+ bool isInitialized() const;
+
private:
void addRules(std::vector<SimplificationRule<Pattern>> const& _rules);
void addRule(SimplificationRule<Pattern> const& _rule);
diff --git a/libjulia/optimiser/SimplificationRules.cpp b/libjulia/optimiser/SimplificationRules.cpp
index a5e296c3..56cb96ac 100644
--- a/libjulia/optimiser/SimplificationRules.cpp
+++ b/libjulia/optimiser/SimplificationRules.cpp
@@ -40,6 +40,7 @@ SimplificationRule<Pattern> const* SimplificationRules::findFirstMatch(Expressio
return nullptr;
static SimplificationRules rules;
+ assertThrow(rules.isInitialized(), OptimizerException, "Rule list not properly initialized.");
FunctionalInstruction const& instruction = boost::get<FunctionalInstruction>(_expr);
for (auto const& rule: rules.m_rules[byte(instruction.instruction)])
@@ -51,6 +52,11 @@ SimplificationRule<Pattern> const* SimplificationRules::findFirstMatch(Expressio
return nullptr;
}
+bool SimplificationRules::isInitialized() const
+{
+ return !m_rules[byte(solidity::Instruction::ADD)].empty();
+}
+
void SimplificationRules::addRules(vector<SimplificationRule<Pattern>> const& _rules)
{
for (auto const& r: _rules)
@@ -79,6 +85,7 @@ SimplificationRules::SimplificationRules()
Y.setMatchGroup(5, m_matchGroups);
addRules(simplificationRuleList(A, B, C, X, Y));
+ assertThrow(isInitialized(), OptimizerException, "Rule list not properly initialized.");
}
Pattern::Pattern(solidity::Instruction _instruction, vector<Pattern> const& _arguments):
diff --git a/libjulia/optimiser/SimplificationRules.h b/libjulia/optimiser/SimplificationRules.h
index 68b640b1..e35e6466 100644
--- a/libjulia/optimiser/SimplificationRules.h
+++ b/libjulia/optimiser/SimplificationRules.h
@@ -51,6 +51,9 @@ public:
/// groups accordingly.
static SimplificationRule<Pattern> const* findFirstMatch(Expression const& _expr);
+ /// Checks whether the rulelist is non-empty. This is usually enforced
+ /// by the constructor, but we had some issues with static initialization.
+ bool isInitialized() const;
private:
void addRules(std::vector<SimplificationRule<Pattern>> const& _rules);
void addRule(SimplificationRule<Pattern> const& _rule);
generated by cgit v1.2.3 (git 2.25.1) at 2025-02-10 18:54:07 +0800