solidity-docs · github-actions · Mar 3, 2026 · Mar 3, 2026 · Mar 3, 2026 · Mar 5, 2026
diff --git a/.readthedocs.yml b/.readthedocs.yml
@@ -1,9 +1,9 @@
 version: 2
 
 build:
-  os: ubuntu-22.04
+  os: ubuntu-24.04
   tools:
-    python: "3.11"
+    python: "3.13"
 
 sphinx:
   builder: html

diff --git a/CMakeLists.txt b/CMakeLists.txt
@@ -1,5 +1,7 @@
 cmake_minimum_required(VERSION 3.13.0)
 
+set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
+
 set(ETH_CMAKE_DIR   "${CMAKE_CURRENT_LIST_DIR}/cmake"   CACHE PATH "The path to the cmake directory")
 list(APPEND CMAKE_MODULE_PATH ${ETH_CMAKE_DIR})
 
@@ -21,7 +23,7 @@ include(EthPolicy)
 eth_policy()
 
 # project name and version should be set after cmake_policy CMP0048
-set(PROJECT_VERSION "0.8.31")
+set(PROJECT_VERSION "0.8.36")
 # OSX target needed in order to support std::visit
 set(CMAKE_OSX_DEPLOYMENT_TARGET "10.14")
 project(solidity VERSION ${PROJECT_VERSION} LANGUAGES C CXX)

diff --git a/docs/050-breaking-changes.rst b/docs/050-breaking-changes.rst
@@ -2,11 +2,19 @@
 Solidity v0.5.0の破壊的変更点
 *****************************
 
+<<<<<<< HEAD
 .. 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>`_.
 
 このセクションでは、Solidityバージョン0.5.0で導入された主な変更点と、変更の理由、影響を受けるコードの更新方法について説明します。
 完全なリストは `リリースのチェンジログ <https://github.com/ethereum/solidity/releases/tag/v0.5.0>`_ を参照してください。
+=======
+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/argotorg/solidity/releases/tag/v0.5.0>`_.
+>>>>>>> english/develop
 
 .. note::
   .. Contracts compiled with Solidity v0.5.0 can still interface with contracts

diff --git a/docs/060-breaking-changes.rst b/docs/060-breaking-changes.rst
@@ -2,8 +2,16 @@
 Solidity v0.6.0の破壊的変更点
 *****************************
 
+<<<<<<< HEAD
 .. This section highlights the main breaking changes introduced in Solidity version 0.6.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.6.0>`_.
+=======
+This section highlights the main breaking changes introduced in Solidity
+version 0.6.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/argotorg/solidity/releases/tag/v0.6.0>`_.
+>>>>>>> english/develop
 
 このセクションでは、Solidityバージョン0.6.0で導入された主な変更点と、変更の理由、影響を受けるコードの更新方法について説明します。
 完全なリストは `リリースチェンジログ <https://github.com/ethereum/solidity/releases/tag/v0.6.0>`_ を参照してください。
@@ -156,8 +164,17 @@ Solidity v0.6.0の破壊的変更点
 * YulとInline Assemblyには、現在の関数を終了させる ``leave`` という新しい文があります。
 * ``address`` から ``address payable`` への変換は ``payable(x)`` を介して可能になりました。
 
+<<<<<<< HEAD
 インターフェースの変更点
 ========================
+=======
+The compiler now appends the `IPFS <https://ipfs.io/>`_ hash of the metadata file to the end of the bytecode by default
+(for details, see documentation on :doc:`contract metadata <metadata>`). Before 0.6.0, the compiler appended the
+`Swarm <https://www.ethswarm.org/>`_ hash by default, and in order to still support this behavior,
+the new command-line option ``--metadata-hash`` was introduced. It allows you to select the hash to be produced and
+appended, by passing either ``ipfs`` or ``swarm`` as value to the ``--metadata-hash`` command-line option.
+Passing the value ``none`` completely removes the hash.
+>>>>>>> english/develop
 
 .. This section lists changes that are unrelated to the language itself, but that have an effect on the interfaces of the compiler.
 .. These may change the way how you use the compiler on the command-line, how you use its programmable interface, or how you analyze the output produced by it.

diff --git a/docs/070-breaking-changes.rst b/docs/070-breaking-changes.rst
@@ -2,11 +2,19 @@
 Solidity v0.7.0の破壊的変更点
 *****************************
 
+<<<<<<< HEAD
 .. This section highlights the main breaking changes introduced in Solidity version 0.7.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.7.0>`_.
 
 このセクションでは、Solidityバージョン0.7.0で導入された主な変更点と、変更の理由、影響を受けるコードの更新方法について説明します。
 完全なリストは `リリースチェンジログ <https://github.com/ethereum/solidity/releases/tag/v0.7.0>`_ を参照してください。
+=======
+This section highlights the main breaking changes introduced in Solidity
+version 0.7.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/argotorg/solidity/releases/tag/v0.7.0>`_.
+>>>>>>> english/develop
 
 
 .. Silent Changes of the Semantics

diff --git a/docs/080-breaking-changes.rst b/docs/080-breaking-changes.rst
@@ -2,8 +2,15 @@
 Solidity v0.8.0の破壊的変更点
 *****************************
 
+<<<<<<< HEAD
 このセクションでは、Solidityのバージョン0.8.0で導入された主な変更点を紹介します。
 完全なリストは `リリースチェンジログ <https://github.com/ethereum/solidity/releases/tag/v0.8.0>`_ を参照してください。
+=======
+This section highlights the main breaking changes introduced in Solidity
+version 0.8.0.
+For the full list check
+`the release changelog <https://github.com/argotorg/solidity/releases/tag/v0.8.0>`_.
+>>>>>>> english/develop
 
 .. Silent Changes of the Semantics
 

diff --git a/docs/_static/css/custom-dark.css b/docs/_static/css/custom-dark.css
@@ -590,6 +590,6 @@
   stroke: white;
 }
 
-:root[style*=dark] .a4 .sig-name {
+:root[style*=dark] .sig-name {
   background-color: transparent !important;
 }
diff --git a/docs/_static/js/constants.js b/docs/_static/js/constants.js
@@ -26,12 +26,12 @@ const CONTRIBUTE_PATH = `/en/latest/contributing.html`;
 const ABOUT_PATH = `${SOLIDITY_HOME_URL}/about`;
 const FORUM_URL = "https://forum.soliditylang.org/";
 const NAV_LINKS = [
-  { name: "Blog", href: BLOG_URL },
-  { name: "Documentation", href: DOCS_URL },
-  { name: "Use cases", href: USE_CASES_PATH },
-  { name: "Contribute", href: CONTRIBUTE_PATH },
-  { name: "About", href: ABOUT_PATH },
-  { name: "Forum", href: FORUM_URL },
+  { name: window.NAV_LINKS.blog, href: BLOG_URL },
+  { name: window.NAV_LINKS.documentation, href: DOCS_URL },
+  { name: window.NAV_LINKS.use_cases, href: USE_CASES_PATH },
+  { name: window.NAV_LINKS.contribute, href: CONTRIBUTE_PATH },
+  { name: window.NAV_LINKS.about, href: ABOUT_PATH },
+  { name: window.NAV_LINKS.forum, href: FORUM_URL },
 ];
 
 const MOBILE_MENU_TOGGLE_CLASS = "shift";

diff --git a/docs/_templates/layout.html b/docs/_templates/layout.html
@@ -1,5 +1,19 @@
 {% extends "!layout.html" %}
 
+{% block scripts %}
+    <script>
+        window.NAV_LINKS = {
+            blog: "{{ _('Blog') }}",
+            documentation: "{{ _('Documentation') }}",
+            use_cases: "{{ _('Use cases') }}",
+            contribute: "{{ _('Contribute') }}",
+            about: "{{ _('About') }}",
+            forum: "{{ _('Forum') }}"
+        };
+    </script>
+    {{ super() }}
+{% endblock %}
+
 {% block menu %}
     {{ super() }}
     <ul>

diff --git a/docs/assembly.rst b/docs/assembly.rst
@@ -57,6 +57,7 @@ Solidityのインラインアセンブリに使用される言語は :ref:`Yul <
     pragma solidity >=0.4.16 <0.9.0;
 
     library GetCode {
+        // This will report a warning - `at` will be promoted to reserved keyword
         function at(address addr) public view returns (bytes memory code) {
             assembly {
                 // コードのサイズを取得します。これはアセンブリが必要です。
@@ -469,12 +470,18 @@ Solidityの複数のバージョンで互換性のあるライブラリを開発
         ...
     }
 
+<<<<<<< HEAD
 .. Note that we will disallow the annotation via comment in a future breaking release; so, if you are not concerned with backward-compatibility with older compiler versions, prefer using the dialect string.
 
 なお、コメントによるアノテーションは、将来のブレーキングリリースで禁止する予定です。
 したがって、古いコンパイラのバージョンとの後方互換性にこだわらない場合は、方言文字列を使用することをお勧めします。
 
 .. TODO:
+=======
+.. warning::
+    The ``memory-safe-assembly`` special comment is deprecated and scheduled for removal.
+    In new code targeting recent compilers, use the assembly block annotation.
+>>>>>>> english/develop
 
 Advanced Safe Use of Memory
 ---------------------------

diff --git a/docs/bugs.json b/docs/bugs.json
@@ -1,4 +1,28 @@
 [
+    {
+        "uid": "SOL-2026-1",
+        "name": "TransientStorageClearingHelperCollision",
+        "summary": "Clearing both storage and transient storage variables in the same contract may result in only one of these locations being cleared.",
+        "description": "The IR-based code generator provides a set of Yul helper functions for basic operations, such as clearing, copying, encoding or type conversions. Not all functions are used by every contract. The codegen appends them to the generated sources individually, only when an operation that would invoke one of them is encountered. Utility functions are often specialized for different types and locations. Since Yul does not support generic functions, specialization is done by generating multiple versions of the same function, with the information distinguishing the variants embedded in their names. However, if not all the necessary bits of distinguishing information are properly accounted for, two helpers may end up with the same name, causing a collision. In this situation the codegen includes only one of them, with calls to both variants invoking it. This happened with the ``set_to_zero`` helper used when an area of transient or persistent storage needs to be cleared. The helper name was missing the location information, which resulted in a collision between the persistent and transient storage variants for the same type. This meant that contracts clearing both locations would actually clear only one, leaving the other untouched. Which location ended up being cleared depended on the order in which the code generator processed the input. The necessary condition to trigger the bug was the use of ``delete`` operator on a transient storage variable. This was due to value types being the only types supported in transient storage and ``delete`` being the only operation invoking the helper allowed on such types. The other necessary condition was clearing of persistent storage and in this case the range of affected operations was wider: operator ``delete``, array ``pop()`` or assignment that resulted in a longer array being overwritten with a shorter one. The cleared variable itself also did not necessarily have to be of the same type. It was enough that a matching value type was nested in it. It also did not always have to be the exact same value type - clearing operations on reference types are usually performed at slot granularity, treating every slot as ``uint256`` rather than clearing every value packed into it individually. To trigger the bug both operations had to be present within the same piece of bytecode. Independent contracts, not related through inheritance, would not affect each other this way. The presence of one operation only in creation code and the other only in deployed code would not trigger the bug either.",
+        "link": "https://blog.soliditylang.org/2026/02/18/transient-storage-clearing-helper-collision-bug/",
+        "introduced": "0.8.28",
+        "fixed": "0.8.34",
+        "severity": "high",
+        "conditions": {
+            "viaIR": true,
+            "evmVersion": ">=cancun"
+        }
+    },
+    {
+        "uid": "SOL-2025-1",
+        "name": "LostStorageArrayWriteOnSlotOverflow",
+        "summary": "Operations that involve clearing or copying from arrays that straddle the end of storage could result in silent data retention.",
+        "description": "Solidity makes it possible to define variables that extend past the last (2**256-th) slot of storage, which results in wrap-around back to slot zero. Since EVM uses 256-bit integer arithmetic, most operations on such variables just work. The only situation which requires special attention is iteration against absolute slot addresses: the invariant that the last slot belonging to a variable has the highest address does not hold. When implemented incorrectly, a loop over an array will immediately terminate if the container spans the end of storage - due to the initial position already being greater than the end position. This affected storage array clearing loops generated by both evmasm and IR pipelines. Additionally, (only in the evmasm pipeline) copying operations whose source was an array straddling the end of storage were also affected. At the language level, the buggy code would be generated for array assignment, array initialization, delete operator, <array>.pop() and <array>.push(). Note that a clearing loop is inserted by the compiler not only for invocations of the delete operator, but also to zero storage when overwriting a longer array with a shorter one, popping an element or even pushing an empty element to a dynamic array. Since clearing is a separate loop, it is possible for the bug to only affect it and not the copy operation it follows (which is always the case in the IR pipeline). The bug is extremely unlikely to be triggered accidentally due to the probabilistic impossibility of a short dynamic array being allocated right at the storage boundary. On the other hand, scenarios in which a user may place a static array there intentionally do not seem realistic and are limited to unusual layouts, in which a contract does not place any storage variables at slot zero (otherwise they would overlap the array).",
+        "link": "https://blog.soliditylang.org/2025/12/18/lost-storage-array-write-on-slot-overflow-bug/",
+        "introduced": "0.1.0",
+        "fixed": "0.8.32",
+        "severity": "low"
+    },
     {
         "uid": "SOL-2023-3",
         "name": "VerbatimInvalidDeduplication",

diff --git a/docs/bugs.rst b/docs/bugs.rst
@@ -6,6 +6,7 @@
 既知のバグのリスト
 ##################
 
+<<<<<<< HEAD
 .. Below, you can find a JSON-formatted list of some of the known security-relevant bugs in the
 .. Solidity compiler. The file itself is hosted in the `GitHub repository
 .. <https://github.com/ethereum/solidity/blob/develop/docs/bugs.json>`_.
@@ -15,6 +16,17 @@
 以下に、Solidityコンパイラのセキュリティ関連の既知のバグをJSON形式でリストアップしています。
 このファイルは  `GitHubリポジトリ <https://github.com/ethereum/solidity/blob/develop/docs/bugs.json>`_  にあります。
 このリストはバージョン0.3.0までさかのぼりますが、それ以前のバージョンにしか存在しないことがわかっているバグはリストに含まれていません。
+=======
+Below, you can find a JSON-formatted list of some of the known security-relevant bugs in the
+Solidity compiler. The file itself is hosted in the `GitHub repository
+<https://github.com/argotorg/solidity/blob/develop/docs/bugs.json>`_.
+The list stretches back as far as version 0.3.0, bugs known to be present only
+in versions preceding that are not listed.
+
+There is another file called `bugs_by_version.json
+<https://github.com/argotorg/solidity/blob/develop/docs/bugs_by_version.json>`_,
+which can be used to check which bugs affect a specific version of the compiler.
+>>>>>>> english/develop
 
 .. There is another file called `bugs_by_version.json
 .. <https://github.com/ethereum/solidity/blob/develop/docs/bugs_by_version.json>`_,