Merge pull request #6188 from ethereum/develop

Release 0.5.5

Author: chriseth

.circleci/config.yml

@@ -56,10 +56,10 @@ jobs:
           paths:
             - boost_1_68_0
       - store_artifacts:
-          path: build/libsolc/soljson.js
+          path: emscripten_build/libsolc/soljson.js
           destination: soljson.js
       - run: mkdir -p workspace
-      - run: cp build/libsolc/soljson.js workspace/soljson.js
+      - run: cp emscripten_build/libsolc/soljson.js workspace/soljson.js
       - run: scripts/get_version.sh > workspace/version.txt
       - persist_to_workspace:
           root: workspace
@@ -202,8 +202,6 @@ jobs:
       - run:
           name: Install build dependencies
           command: |
-            brew update
-            brew upgrade
             brew unlink python
             brew install z3
             brew install boost
@@ -353,8 +351,6 @@ jobs:
       - run:
           name: Install dependencies
           command: |
-            brew update
-            brew upgrade
             brew unlink python
             brew install z3
       - run: mkdir -p test_results

.gitignore

@@ -32,6 +32,7 @@ prerelease.txt
 
 # Build directory
 build/
+emscripten_build/
 docs/_build
 docs/utils/__pycache__
 docs/utils/*.pyc

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.4")
+set(PROJECT_VERSION "0.5.5")
 project(solidity VERSION ${PROJECT_VERSION} LANGUAGES CXX)
 
 option(LLL "Build LLL" OFF)

Changelog.md

@@ -1,3 +1,43 @@
+### 0.5.5 (2019-03-05)
+
+Language Features:
+ * Add support for getters of mappings with ``string`` or ``bytes`` key types.
+ * Meta programming: Provide access to the name of contracts via ``type(C).name``.
+
+
+Compiler Features:
+ * Support ``petersburg`` as ``evmVersion`` and set as default.
+ * 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.
+ * 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.
+ * Optimizer: Combine multiple shifts with constant shift-by values into one.
+ * Optimizer: Do not mask with 160-bits after ``CREATE`` and ``CREATE2`` as they are guaranteed to return an address or 0.
+ * Optimizer: Support shifts in the constant optimiser for Constantinople.
+ * Yul Optimizer: Add rule to replace switch statements with literals by matching case body.
+
+
+Bugfixes:
+ * ABIEncoderV2: Fix internal error related to bare delegatecall.
+ * ABIEncoderV2: Fix internal error related to ecrecover.
+ * ABIEncoderV2: Fix internal error related to mappings as library parameters.
+ * ABIEncoderV2: Fix invalid signature for events containing structs emitted in libraries.
+ * Inline Assembly: Proper error message for missing variables.
+ * Optimizer: Fix internal error related to unused tag removal across assemblies. This never generated any invalid code.
+ * SMTChecker: Fix crash related to statically-sized arrays.
+ * TypeChecker: Fix internal error and disallow index access on contracts and libraries.
+ * Yul: Properly detect name clashes with functions before their declaration.
+ * Yul: Take built-in functions into account in the compilability checker.
+ * Yul Optimizer: Properly take reassignments to variables in sub-expressions into account when replacing in the ExpressionSimplifier.
+
+
+Build System:
+ * Soltest: Add support for left-aligned, padded hex literals.
+ * Soltest: Add support for right-aligned, padded boolean literals.
+
 ### 0.5.4 (2019-02-12)
 
 Language Features:

ReleaseChecklist.md

@@ -1,24 +1,51 @@
-Checklist for making a release:
+## Checklist for making a release:
 
+### Requirements
+ - [ ] Lauchpad (Ubuntu One) account
+ - [ ] gnupg key (has to be version 1, gpg2 won't work) for `[email protected]` created and uploaded
+ - [ ] Readthedocs account, access to the Solidity project
+ - [ ] Write access to https://github.com/ethereum/homebrew-ethereum
+
+### Pre-release
  - [ ] Ensure that a Github project exists for the release.
  - [ ] Check that all issues and pull requests from the Github project to be released are merged to ``develop``.
- - [ ] Create a commit in ``develop`` that updates the ``Changelog`` to include a release date (run ``./scripts/tests.sh`` to update the bug list). Sort the changelog entries alphabetically and correct any errors you notice.
+
+### Changelog
+ - [ ] Sort the changelog entries alphabetically and correct any errors you notice.
+ - [ ] Create a commit on a new branch that updates the ``Changelog`` to include a release date.
+ - [ ] Run ``./scripts/tests.sh`` to update the bug list.
  - [ ] Create a pull request and wait for the tests, merge it.
+
+### Create the Release
+ - [ ] Create Github release page: https://github.com/ethereum/solidity/releases/new
+ - [ ] On the release page, select the ``release`` branch as new target and set tag to the new version (e.g. `v0.5.4`) (make sure you only `SAVE DRAFT` instead of `PUBLISH RELEASE` before the actual release)
  - [ ] Thank voluntary contributors in the Github release page (use ``git shortlog -s -n -e origin/release..origin/develop``).
  - [ ] Create a pull request from ``develop`` to ``release``, wait for the tests, then merge it.
  - [ ] Make a final check that there are no platform-dependency issues in the ``solidity-test-bytecode`` repository.
  - [ ] Wait for the tests for the commit on ``release``, create a release in Github, creating the tag.
- - [ ] Wait for the CI runs on the tag itself (they should push artifacts onto the Github release page).
- - [ ] Run ``scripts/create_source_tarball.sh`` while being on the tag to create the source tarball.
- - [ ] Upload the source tarball (in the upload directory) to the release page.
+ - [ ] Wait for the CI runs on the tag itself (travis and appveyor should push artifacts onto the Github release page).
+ - [ ] Run ``scripts/create_source_tarball.sh`` while being on the tag to create the source tarball. Make sure to create ``prerelease.txt`` before: (``echo -n > prerelease.txt``). This will create the tarball in a directory called ``upload``.
+ - [ ] Take the tarball from the upload directory (its name should be ``solidity_x.x.x.tar.gz``, otherwise ``prerelease.txt`` was missing in the step before) and upload the source tarball to the release page.
+ - [ ] Click the `PUBLISH RELEASE` button on the release page.
+
+### PPA
+ - [ ] Change ``scripts/release_ppa.sh`` to match your key's email and key id.
  - [ ] Run ``scripts/release_ppa.sh release`` to create the PPA release (you need the relevant openssl key).
- - [ ] Once the ``~ethereum/ubuntu/ethereum-static`` PPA build is finished and published for all platforms (make sure not to do this earlier), copy the static package to the ``~ethereum/ubuntu/ethereum`` PPA for the destination series ``Trusty`` and ``Xenial`` while selecting ``Copy existing binaries``.
- - [ ] Check that the Docker release was pushed to Docker Hub (this still seems to have problems, run ``./scripts/docker_deploy_manual.sh release``).
- - [ ] Update the homebrew realease in https://github.com/ethereum/homebrew-ethereum/blob/master/solidity.rb (version and hash)
+ - [ ] Wait for the ``~ethereum/ubuntu/ethereum-static`` PPA build to be finished and published for *all platforms*. SERIOUSLY: DO NOT PROCEED EARLIER!!! *After* the static builds are *published*, copy the static package to the ``~ethereum/ubuntu/ethereum`` PPA for the destination series ``Trusty`` and ``Xenial`` while selecting ``Copy existing binaries``.
+ - [ ] Check that the Docker release was pushed to Docker Hub (this still seems to have problems, run ``./scripts/docker_deploy_manual.sh v0.x.x``).
+
+### Homebrew
+ - [ ] 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.
- - [ ] Make a release of ``solc-js``: Increment the version number, create a pull request for that, merge it after tests succeeded.
+
+### 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
  - [ ] Announce on Twitter and Reddit.
  - [ ] Lean back, wait for bug reports and repeat from step 1 :)

codecov.yml

@@ -3,6 +3,10 @@ codecov:
 coverage:
   range: 70...100
   status:
+    patch:
+      default:
+        target: "50%"
+        paths: "!test/"
     project:
       default:
         target: auto

docs/assembly.rst

@@ -162,7 +162,6 @@ Note that the order of arguments can be seen to be reversed in non-functional st
 Opcodes marked with ``-`` do not push an item onto the stack (do not return a result),
 those marked with ``*`` are special and all others push exactly one item onto the stack (their "return value").
 Opcodes marked with ``F``, ``H``, ``B`` or ``C`` are present since Frontier, Homestead, Byzantium or Constantinople, respectively.
-Constantinople is still in planning and all instructions marked as such will result in an invalid instruction exception.
 
 In the following, ``mem[a...b)`` signifies the bytes of memory starting at position ``a`` up to
 but not including position ``b`` and ``storage[p]`` signifies the storage contents at position ``p``.

docs/bugs_by_version.json

@@ -628,5 +628,9 @@
     "0.5.4": {
         "bugs": [],
         "released": "2019-02-12"
+    },
+    "0.5.5": {
+        "bugs": [],
+        "released": "2019-03-05"
     }
 }

docs/contributing.rst

@@ -90,7 +90,7 @@ The option ``--no-smt`` disables the tests that require ``libz3`` and
 ``--no-ipc`` disables those that require ``aleth``.
 
 If you want to run the ipc tests (that test the semantics of the generated code),
-you need to install `aleth <https://github.com/ethereum/aleth/releases/download/v1.5.0-alpha.7/aleth-1.5.0-alpha.7-linux-x86_64.tar.gz>`_ and run it in testing mode: ``aleth --db memorydb --test -d /tmp/testeth``.
+you need to install `aleth <https://github.com/ethereum/aleth/releases/download/v1.5.2/aleth-1.5.2-linux-x86_64.tar.gz>`_ and run it in testing mode: ``aleth --db memorydb --test -d /tmp/testeth``.
 
 To run the actual tests, use: ``./scripts/soltest.sh --ipcpath /tmp/testeth/geth.ipc``.
 
@@ -326,3 +326,82 @@ escaping and without iterated replacements. An area can be delimited by ``<#name
 by as many concatenations of its contents as there were sets of variables supplied to the template system,
 each time replacing any ``<inner>`` items by their respective value. Top-level variables can also be used
 inside such areas.
+
+.. _documentation-style:
+
+Documentation Style Guide
+=========================
+
+The following are style recommendations specifically for documentation
+contributions to Solidity.
+
+English Language
+----------------
+
+Use English, with British English spelling preferred, unless using project or brand names. Try to reduce the usage of
+local slang and references, making your language as clear to all readers as possible. Below are some references to help:
+
+* `Simplified technical English <https://en.wikipedia.org/wiki/Simplified_Technical_English>`_
+* `International English <https://en.wikipedia.org/wiki/International_English>`_
+* `British English spelling <https://en.oxforddictionaries.com/spelling/british-and-spelling>`_
+
+
+.. note::
+
+    While the official Solidity documentation is written in English, there are community contributed :ref:`translations`
+    in other languages available.
+
+Title Case for Headings
+-----------------------
+
+Use `title case <http://titlecase.com>`_ for headings. This means capitalise all principal words in
+titles, but not articles, conjunctions, and prepositions unless they start the
+title.
+
+For example, the following are all correct:
+
+* Title Case for Headings
+* For Headings Use Title Case
+* Local and State Variable Names
+* Order of Layout
+
+Expand Contractions
+-------------------
+
+Use expanded contractions for words, for example:
+
+* "Do not" instead of "Don't".
+* "Can not" instead of "Can't".
+
+Active and Passive Voice
+------------------------
+
+Active voice is typically recommended for tutorial style documentation as it
+helps the reader understand who or what is performing a task. However, as the
+Solidity documentation is a mixture of tutorials and reference content, passive
+voice is sometimes more applicable.
+
+As a summary:
+
+* Use passive voice for technical reference, for example language definition and internals of the Ethereum VM.
+* Use active voice when describing recommendations on how to apply an aspect of Solidity.
+
+For example, the below is in passive voice as it specifies an aspect of Solidity:
+
+  Functions can be declared ``pure`` in which case they promise not to read
+  from or modify the state.
+
+For example, the below is in active voice as it discusses an application of Solidity:
+
+  When invoking the compiler, you can specify how to discover the first element
+  of a path, and also path prefix remappings.
+
+Common Terms
+------------
+
+* "Function parameters" and "return variables", not input and output parameters.
+
+Code Examples
+-------------
+
+* Ensure that all code examples begin with a ``pragma`` version that spans the largest where the contract code is valid. For example ``pragma solidity >=0.4.0 <0.6.0;``.

docs/control-structures.rst

@@ -91,7 +91,7 @@ You need to use the modifier ``payable`` with the ``info`` function because
 otherwise, the ``.value()`` option would not be available.
 
 .. warning::
-  Be careful that ``feed.info.value(10).gas(800)`` only locally sets the ``value`` and amount of ``gas`` sent with the function call, and the parentheses at the end perform the actual call. So in this case, the function is not called.
+  Be careful that ``feed.info.value(10).gas(800)`` only locally sets the ``value`` and amount of ``gas`` sent with the function call, and the 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