Merge pull request #6269 from ethereum/develop

Merge develop into release for 0.5.6

CMakeLists.txt

@@ -10,7 +10,7 @@ include(EthPolicy)
 eth_policy()
 
 # project name and version should be set after cmake_policy CMP0048
-set(PROJECT_VERSION "0.5.5")
+set(PROJECT_VERSION "0.5.6")
 project(solidity VERSION ${PROJECT_VERSION} LANGUAGES CXX)
 
 option(LLL "Build LLL" OFF)

Changelog.md

@@ -1,3 +1,35 @@
+### 0.5.6 (2019-03-13)
+
+Important Bugfixes:
+ * Yul Optimizer: Fix visitation order bug for the structural simplifier.
+ * Optimizer: Fix overflow in optimization rule that simplifies double shift by constant.
+
+Language Features:
+ * Allow calldata arrays with dynamically encoded base types with ABIEncoderV2.
+ * Allow dynamically encoded calldata structs with ABIEncoderV2.
+
+
+Compiler Features:
+ * Optimizer: Add rules for ``lt``-comparisons with constants.
+ * Peephole Optimizer: Remove double ``iszero`` before ``jumpi``.
+ * SMTChecker: Support enums without typecast.
+ * SMTChecker: Support one-dimensional arrays.
+ * Type Checker: Provide better error messages for some literal conversions.
+ * Yul Optimizer: Add rule to remove empty default switch cases.
+ * Yul Optimizer: Add rule to remove empty cases if no default exists.
+ * Yul Optimizer: Add rule to replace a switch with no cases with ``pop(expression)``.
+
+
+Bugfixes:
+ * JSON ABI: Json description of library ABIs no longer contains functions with internal types like storage structs.
+ * SMTChecker: Fix internal compiler error when contract contains too large rational number.
+ * Type system: Detect if a contract's base uses types that require the experimental abi encoder while the contract still uses the old encoder.
+
+
+Build System:
+ * Soltest: Add support for arrays in function signatures.
+ * Soltest: Add support for struct arrays in function signatures.
+
 ### 0.5.5 (2019-03-05)
 
 Language Features:
@@ -7,10 +39,12 @@ Language Features:
 
 Compiler Features:
  * Support ``petersburg`` as ``evmVersion`` and set as default.
+ * Commandline Interface: Option to activate the experimental yul optimizer using ``-optimize-yul``.
  * Inline Assembly: Consider ``extcodehash`` as part of Constantinople.
  * Inline Assembly: Instructions unavailable to the currently configured EVM are errors now.
  * SMTChecker: Do not report underflow/overflow if they always revert. This removes false positives when using ``SafeMath``.
  * Standard JSON Interface: Allow retrieving metadata without triggering bytecode generation.
+ * Standard JSON Interface: Provide fine-grained control over the optimizer via the settings.
  * Static Analyzer: Warn about expressions with custom types when they have no effect.
  * Optimizer: Add new rules with constants including ``LT``, ``GT``, ``AND`` and ``BYTE``.
  * Optimizer: Add rule for shifts with constants for Constantinople.
@@ -36,6 +70,7 @@ Bugfixes:
 
 Build System:
  * Soltest: Add support for left-aligned, padded hex literals.
+ * Soltest: Add support for left-aligned, unpadded hex string literals.
  * Soltest: Add support for right-aligned, padded boolean literals.
 
 ### 0.5.4 (2019-02-12)

ReleaseChecklist.md

@@ -38,14 +38,15 @@
  - [ ] Update the version and the hash (``sha256sum solidity_x.x.x.tar.gz``) in https://github.com/ethereum/homebrew-ethereum/blob/master/solidity.rb
 
 ### Documentation
- - [ ] Update the default version on readthedocs.
+ - [ ] Build the new version on https://readthedocs.org/projects/solidity/ (select `latest` on the bottom of the page and click `BUILD`)
+ - [ ] In the admin panel, select `Versions` in the menu and set the default version to the released one.
 
 ### Release solc-js
  - [ ] Increment the version number, create a pull request for that, merge it after tests succeeded.
  - [ ] Run ``npm publish`` in the updated ``solc-js`` repository.
- - [ ] Create a commit to increase the version number on ``develop`` in ``CMakeLists.txt`` and add a new skeleton changelog entry.
- - [ ] Merge ``release`` back into ``develop``.
 
 ### Post-release
+ - [ ] Create a commit to increase the version number on ``develop`` in ``CMakeLists.txt`` and add a new skeleton changelog entry.
+ - [ ] Merge ``release`` back into ``develop``.
  - [ ] Announce on Twitter and Reddit.
  - [ ] Lean back, wait for bug reports and repeat from step 1 :)

docs/050-breaking-changes.rst

@@ -308,7 +308,7 @@ This will no longer compile with Solidity v0.5.0. However, you can define a comp
 
 ::
 
-   pragma solidity ^0.5.0;
+   pragma solidity >=0.5.0 <0.7.0;
    interface OldContract {
       function someOldFunction(uint8 a) external;
       function anotherOldFunction() external returns (bool);
@@ -325,7 +325,7 @@ Given the interface defined above, you can now easily use the already deployed p
 
 ::
 
-   pragma solidity ^0.5.0;
+   pragma solidity >=0.5.0 <0.7.0;
 
    interface OldContract {
       function someOldFunction(uint8 a) external;
@@ -345,7 +345,7 @@ commandline compiler for linking):
 
 ::
 
-   pragma solidity ^0.5.0;
+   pragma solidity >=0.5.0 <0.7.0;
 
    library OldLibrary {
       function someFunction(uint8 a) public returns(bool);
@@ -430,7 +430,7 @@ New version:
 
 ::
 
-   pragma solidity ^0.5.0;
+   pragma solidity >=0.5.0 <0.7.0;
 
    contract OtherContract {
       uint x;

docs/abi-spec.rst

@@ -212,7 +212,7 @@ Given the contract:
 
 ::
 
-    pragma solidity >=0.4.16 <0.6.0;
+    pragma solidity >=0.4.16 <0.7.0;
 
     contract Foo {
       function bar(bytes3[2] memory) public pure {}
@@ -483,7 +483,7 @@ For example,
 
 ::
 
-    pragma solidity ^0.5.0;
+    pragma solidity >=0.5.0 <0.7.0;
 
     contract Test {
       constructor() public { b = hex"12345678901234567890123456789012"; }
@@ -530,7 +530,7 @@ As an example, the code
 
 ::
 
-    pragma solidity >=0.4.19 <0.6.0;
+    pragma solidity >=0.4.19 <0.7.0;
     pragma experimental ABIEncoderV2;
 
     contract Test {

docs/assembly.rst

@@ -76,7 +76,7 @@ idea is that assembly libraries will be used to enhance the Solidity language.
 
 .. code::
 
-    pragma solidity >=0.4.0 <0.6.0;
+    pragma solidity >=0.4.0 <0.7.0;
 
     library GetCode {
         function at(address _addr) public view returns (bytes memory o_code) {
@@ -101,7 +101,7 @@ efficient code, for example:
 
 .. code::
 
-    pragma solidity >=0.4.16 <0.6.0;
+    pragma solidity >=0.4.16 <0.7.0;
 
     library VectorSum {
         // This function is less efficient because the optimizer currently fails to
@@ -394,7 +394,7 @@ Local Solidity variables are available for assignments, for example:
 
 .. code::
 
-    pragma solidity >=0.4.11 <0.6.0;
+    pragma solidity >=0.4.11 <0.7.0;
 
     contract C {
         uint b;
@@ -433,7 +433,7 @@ be just ``0``, but it can also be a complex functional-style expression.
 
 .. code::
 
-    pragma solidity >=0.4.16 <0.6.0;
+    pragma solidity >=0.4.16 <0.7.0;
 
     contract C {
         function f(uint x) public view returns (uint b) {
@@ -690,7 +690,7 @@ Example:
 We will follow an example compilation from Solidity to assembly.
 We consider the runtime bytecode of the following Solidity program::
 
-    pragma solidity >=0.4.16 <0.6.0;
+    pragma solidity >=0.4.16 <0.7.0;
 
     contract C {
       function f(uint x) public pure returns (uint y) {

docs/bugs.json

@@ -1,4 +1,16 @@
 [
+    {
+        "name": "DoubleShiftSizeOverflow",
+        "summary": "Double bitwise shifts by large constants whose sum overflows 256 bits can result in unexpected values.",
+        "description": "Nested logical shift operations whose total shift size is 2**256 or more are incorrectly optimized. This only applies to shifts by numbers of bits that are compile-time constant expressions.",
+        "introduced": "0.5.5",
+        "fixed": "0.5.6",
+        "severity": "low",
+        "conditions": {
+            "optimizer": true,
+            "evmVersion": ">=constantinople"
+        }
+    },
     {
         "name": "ExpExponentCleanup",
         "summary": "Using the ** operator with an exponent of type shorter than 256 bits can result in unexpected values.",

docs/bugs.rst

@@ -52,9 +52,15 @@ severity
     discoverability in contract tests, likelihood of occurrence and
     potential damage by exploits.
 conditions
-    Conditions that have to be met to trigger the bug. Currently, this
-    is an object that can contain a boolean value ``optimizer``, which
+    Conditions that have to be met to trigger the bug. The following
+    keys can be used:
+    ``optimizer``, Boolean value which
     means that the optimizer has to be switched on to enable the bug.
+    ``evmVersion``, a string that indicates which EVM version compiler
+    settings trigger the bug. The string can contain comparison
+    operators. For example, ``">=constantinople"`` means that the bug
+    is present when the EVM version is set to ``constantinople`` or
+    later.
     If no conditions are given, assume that the bug is present.
 check
     This field contains different checks that report whether the smart contract

docs/bugs_by_version.json

@@ -630,7 +630,13 @@
         "released": "2019-02-12"
     },
     "0.5.5": {
-        "bugs": [],
+        "bugs": [
+            "DoubleShiftSizeOverflow"
+        ],
         "released": "2019-03-05"
+    },
+    "0.5.6": {
+        "bugs": [],
+        "released": "2019-03-13"
     }
 }

docs/common-patterns.rst

@@ -28,7 +28,7 @@ become the new richest.
 
 ::
 
-    pragma solidity ^0.5.0;
+    pragma solidity >=0.5.0 <0.7.0;
 
     contract WithdrawalContract {
         address public richest;
@@ -65,7 +65,7 @@ This is as opposed to the more intuitive sending pattern:
 
 ::
 
-    pragma solidity ^0.5.0;
+    pragma solidity >=0.5.0 <0.7.0;
 
     contract SendContract {
         address payable public richest;
@@ -130,7 +130,7 @@ restrictions highly readable.
 
 ::
 
-    pragma solidity >=0.4.22 <0.6.0;
+    pragma solidity >=0.4.22 <0.7.0;
 
     contract AccessRestriction {
         // These will be assigned at the construction
@@ -282,7 +282,7 @@ function finishes.
 
 ::
 
-    pragma solidity >=0.4.22 <0.6.0;
+    pragma solidity >=0.4.22 <0.7.0;
 
     contract StateMachine {
         enum Stages {

docs/contracts/abstract-contracts.rst

@@ -8,15 +8,15 @@ Abstract Contracts
 
 Contracts are marked as abstract when at least one of their functions lacks an implementation as in the following example (note that the function declaration header is terminated by ``;``)::
 
-    pragma solidity >=0.4.0 <0.6.0;
+    pragma solidity >=0.4.0 <0.7.0;
 
     contract Feline {
         function utterance() public returns (bytes32);
     }
 
 Such contracts cannot be compiled (even if they contain implemented functions alongside non-implemented functions), but they can be used as base contracts::
 
-    pragma solidity >=0.4.0 <0.6.0;
+    pragma solidity >=0.4.0 <0.7.0;
 
     contract Feline {
         function utterance() public returns (bytes32);

docs/contracts/constant-state-variables.rst

@@ -26,7 +26,7 @@ value types and strings.
 
 ::
 
-    pragma solidity >=0.4.0 <0.6.0;
+    pragma solidity >=0.4.0 <0.7.0;
 
     contract C {
         uint constant x = 32**22 + 8;

docs/contracts/creating-contracts.rst

@@ -33,7 +33,7 @@ This means that cyclic creation dependencies are impossible.
 
 ::
 
-    pragma solidity >=0.4.22 <0.6.0;
+    pragma solidity >=0.4.22 <0.7.0;
 
     contract OwnedToken {
         // `TokenCreator` is a contract type that is defined below.

docs/contracts/events.rst

@@ -63,7 +63,7 @@ not possible to filter for specific anonymous events by name.
 
 ::
 
-    pragma solidity >=0.4.21 <0.6.0;
+    pragma solidity >=0.4.21 <0.7.0;
 
     contract ClientReceipt {
         event Deposit(
@@ -136,7 +136,7 @@ as topics. The event call above can be performed in the same way as
 
 ::
 
-    pragma solidity >=0.4.10 <0.6.0;
+    pragma solidity >=0.4.10 <0.7.0;
 
     contract C {
         function f() public payable {

docs/contracts/function-modifiers.rst

@@ -12,7 +12,7 @@ inheritable properties of contracts and may be overridden by derived contracts.
 
 ::
 
-    pragma solidity ^0.5.0;
+    pragma solidity >=0.5.0 <0.7.0;
 
     contract owned {
         constructor() public { owner = msg.sender; }