solidity-docs · github-actions · May 20, 2026 · May 20, 2026 · May 20, 2026 · May 20, 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.37")
 # OSX target needed in order to support std::visit
 set(CMAKE_OSX_DEPLOYMENT_TARGET "10.14")
 project(solidity VERSION ${PROJECT_VERSION} LANGUAGES C CXX)
@@ -129,7 +131,6 @@ add_subdirectory(libevmasm)
 add_subdirectory(libyul)
 add_subdirectory(libsolidity)
 add_subdirectory(libsolc)
-add_subdirectory(libstdlib)
 
 if (NOT ONLY_BUILD_SOLIDITY_LIBRARIES)
 	add_subdirectory(tools)

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/css/custom.css b/docs/_static/css/custom.css
@@ -469,6 +469,20 @@ footer .rst-footer-buttons {
     border-bottom: 1px solid var(--color-c);
 }
 
+/* Read the Docs Addons version-warning notification.
+   The addon hardcodes top:2rem / z-index:1750 inside its shadow DOM, so the
+   fixed site header (--navHeight tall, z-index:99999) both overlaps and covers
+   it. Style the host element to sit below the header and above its z-index;
+   the transform makes the host the containing block for the addon's fixed
+   toast, shifting its internal top:2rem offset down past the header. */
+readthedocs-notification {
+    position: fixed;
+    top: var(--navHeight);
+    right: 0;
+    z-index: 100000;
+    transform: translateZ(0);
+}
+
 /* Rest: Flex-row, with two children: side bar, and content */
 .unified-wrapper .wy-grid-for-nav {
     position: relative !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,26 @@
 {% extends "!layout.html" %}
 
+{% block extrahead %}
+    {{ super() }}
+    {% if github_version not in allowed_indexed_versions %}
+        <meta name="robots" content="noindex, follow">
+    {% endif %}
+{% endblock %}
+
+{% 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,51 @@
 [
+    {
+        "uid": "SOL-2026-3",
+        "name": "InheritanceOrderReversalOnStorageEndWarning",
+        "summary": "Emitting a warning about storage base location being too close to the storage end unintentionally reversed the ``linearizedBaseContracts`` annotation, possibly leading to miscompilation due to reversing the order in which inheritance is resolved.",
+        "description": "When the compiler detects that a custom layout specifier puts contract's static storage area too close to the end of the address space, it emits a warning. To make the warning more useful, the compiler tries to point at the last storage variable in that area. For this reason it walks the linearized inheritance hierarchy in reverse (from the least to the most derived). The list is calculated once and stored in an AST annotation called ``linearizedBaseContracts``. The direct cause of the bug was the fact that the code that reverses the list was doing it in place rather than on a copy, modifying the annotation. This effectively reversed the order of base contracts seen by any component that runs after layout checks: later phases of analysis, AST export, code generator, SMTChecker, etc. The observable effect was a reversed order of state variable initialization, constructor invocation, virtual function/modifier resolution, leading either to miscompilations or internal compiler errors, depending on the specific usage. Since the source of the bug was in the analysis stage, it was independent of the codegen pipeline or optimizer settings. The main condition necessary to trigger the bug was the presence of the warning in the output. The other is presence of language constructs whose evaluation depends on the inheritance order. While potential effects are very serious, this requirement excludes the vast majority of contracts as intentionally placing the storage variables in the last 2**64 slots is highly discouraged, which was actually the main reason for adding this warning.",
+        "link": "https://blog.soliditylang.org/2026/07/09/inheritance-order-reversal-on-storage-end-warning-bug/",
+        "introduced": "0.8.29",
+        "fixed": "0.8.36",
+        "severity": "medium"
+    },
+    {
+        "uid": "SOL-2026-2",
+        "name": "UnsoundSpillInMutualRecursion",
+        "summary": "Local variables of a function involved in mutual recursion may spuriously be moved to fixed memory offsets and overwritten across recursive calls.",
+        "description": "To work around the 16-slot stack access limit of the EVM, the IR-based code generator can move local variables of stack-too-deep functions to fixed memory offsets. This relocation is unsound for recursive functions: a fixed offset would be shared by all activations of the function, so a recursive call would overwrite the caller's value. The stack limit evader therefore must not relocate variables of functions that are part of a recursive call chain. To this end, the call graph was searched for cycles using a path-based depth-first search that, once a function had been fully explored and popped from the search path, short-circuited on it on any later visit. As a result, a function shared between several intersecting cycles could be reached first through a path that did not yet close a cycle through it, get marked as finished, and then be skipped when a later path would have revealed that it does lie on a cycle. Such a function was misclassified as non-recursive. When a misclassified function was complex enough for the stack limit evader to relocate some of its variables, those variables were moved to fixed memory offsets and silently corrupted on recursion, producing wrong results rather than a compile-time error. Triggering the bug requires the IR pipeline, a set of mutually recursive functions whose call graph contains intersecting cycles, at least one of the functions in an undetected part of a cycle being complex enough to require relocation to memory, and an unfortunate processing order of the functions (which depends on the hashes of their Yul names). It is independent of whether the optimizer is enabled.",
+        "link": "https://blog.soliditylang.org/2026/07/09/unsound-spill-in-mutual-recursion-bug/",
+        "introduced": "0.7.2",
+        "fixed": "0.8.36",
+        "severity": "medium",
+        "conditions": {
+            "viaIR": true
+        }
+    },
+    {
+        "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",