update docs (#458)

Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>

book/src/roadmap.md

@@ -1,6 +1,6 @@
-# Roadmap and Vision
+# Vision and Roadmap
 
-The `revive` compiler speeds up Solidity contracts by orders of magnitude. `revive` provides a decisive edge over other contract platforms. Notably, the compiler eliminates the need of rewriting Solidity dApps as single dApp parachains for scaling reasons. Retaining as high compatibility with Ethereum Solidity as possible keeps entry barriers low.
+The `revive` compiler speeds up Solidity contracts significantly. `revive` provides a decisive edge over other contract platforms. Notably, the compiler eliminates the need of rewriting Solidity dApps in Rust or even as single dApp parachains for scaling reasons. Retaining as high compatibility with Ethereum Solidity as possible keeps entry barriers low.
 
 We believe in Dr. Gavin Wood's [ĐApps: What Web 3.0 Looks Like](https://gavwood.com/dappsweb3.html) manifesto and the ecosystem of the Solidity programming language. Our motivation lies in the realization that for a _true_ web3 revolution, significant scaling efforts, like the ones provided by the PVM and this project, are necessary to unfold.
 

book/src/user_guide.md

@@ -1,6 +1,6 @@
 # `resolc` user guide
 
-`resolc` is a Solidity `v0.8` compiler for [Polkadot `native` smart contracts](https://docs.polkadot.com/develop/smart-contracts/overview/#native-smart-contracts). Solidity compiled with `resolc` executes orders of magnitude faster than the EVM. `resolc`  also supports almost all Solidity `v0.8` features including inline assembly, offering a high level of comptability with the Ethereum Solidity reference implementation.
+`resolc` is a Solidity `v0.8` compiler for [Polkadot `native` smart contracts](https://docs.polkadot.com/develop/smart-contracts/overview/#native-smart-contracts). Solidity compiled with `resolc` targets PolaVM (PVM). Thanks to additional compiler optimizations and the PVM JIT, contract code can execute much faster than the EVM equivalent. `resolc`  supports almost all Solidity `v0.8` features including inline assembly, offering a high level of comptability with the Ethereum Solidity reference implementation.
 
 ## `revive` vs. `resolc` nomenclature
 

book/src/user_guide/differences.md

@@ -35,7 +35,7 @@ The `solc` compiler ought to always emit valid memory references, so Solidity dA
 ### `mload`, `mstore`, `msize`, `mcopy` (memory related functions) 
 
 In general, revive preserves the memory layout, meaning low level memory operations are supported. However, a few caveats apply:
-- The EVM linear heap memory is emulated using a fixed byte buffer of 64kb. This implies that the maximum memory a contract can use is limited to 64kbit (on Ethereum, contract memory is capped by gas and therefore varies).
+- The EVM linear heap memory is emulated using a fixed byte buffer of 128kb. This implies that the maximum memory a contract can use is limited to 128kb (on Ethereum, contract memory is capped by gas and therefore varies).
 - Thus, accessing memory offsets larger than the fixed buffer size will trap the contract at runtime with an `OutOfBound` error.
 - The compiler might detect and optimize unused memory reads and writes, leading to a different `msize` compared to what the EVM would see. 
 
@@ -60,7 +60,7 @@ Thus, `revive` is able to supply the expected code hash and constructor argument
 
 > [!WARNING]
 >
-> This might fall apart in code creating contracts inside `assembly` blocks. **We strongly discourage using the `create` family opcodes to manually craft deployments in `assembly` blocks!** Usually, the reason for using `assembly` blocks is to save gas, which is futile on revive anyways due to lower transaction costs.
+> This might fall apart in code creating contracts inside `assembly` blocks. **We strongly discourage using the `create` family opcodes to manually craft deployments in `assembly` blocks!** Usually, the reason for using `assembly` blocks is to save gas, which is likely futile on revive due to the underlying differences in the VM architectures, gas models and transaction costs.
 
 ### `dataoffset`
 
@@ -88,3 +88,34 @@ There are two different compilation pipelines available in `solc` and [there are
 
 Since `resolc` processes the YUL IR, always assume the `solc` IR based codegen behavior for contracts compiled with the `revive` compiler.
 
+### Example: State variable initialization order in inheritance
+
+With `via-ir`, base constructors run before derived state variables are initialized:
+
+```solidity
+contract InnerContract {
+    uint public innerConstructedStartTokenId;
+
+    constructor() {
+        innerConstructedStartTokenId = _startTokenId();
+    }
+
+    function _startTokenId() internal view virtual returns (uint) {
+        return 0;
+    }
+}
+
+contract Test is InnerContract {
+    uint public START_TOKEN_ID = 1;
+
+    constructor() InnerContract() {
+    }
+
+    function _startTokenId() internal view virtual override returns (uint) {
+        return START_TOKEN_ID;
+    }
+}
+```
+
+Here, `innerConstructedStartTokenId` in `Test` returns `0` (with legacy EVM codegen it'd return `1`).
+

docs/404.html

@@ -36,7 +36,7 @@
             const path_to_root = "";
             const default_light_theme = "light";
             const default_dark_theme = "navy";
-            window.path_to_searchindex_js = "searchindex-8c3ce0af.js";
+            window.path_to_searchindex_js = "searchindex-4ae832c1.js";
         </script>
         <!-- Start loading toc.js asap -->
         <script src="toc-6f3f265e.js"></script>

docs/developer_guide.html

@@ -35,7 +35,7 @@
             const path_to_root = "";
             const default_light_theme = "light";
             const default_dark_theme = "navy";
-            window.path_to_searchindex_js = "searchindex-8c3ce0af.js";
+            window.path_to_searchindex_js = "searchindex-4ae832c1.js";
         </script>
         <!-- Start loading toc.js asap -->
         <script src="toc-6f3f265e.js"></script>

docs/developer_guide/architecture.html

@@ -35,7 +35,7 @@
             const path_to_root = "../";
             const default_light_theme = "light";
             const default_dark_theme = "navy";
-            window.path_to_searchindex_js = "../searchindex-8c3ce0af.js";
+            window.path_to_searchindex_js = "../searchindex-4ae832c1.js";
         </script>
         <!-- Start loading toc.js asap -->
         <script src="../toc-6f3f265e.js"></script>

docs/developer_guide/contributing.html

@@ -35,7 +35,7 @@
             const path_to_root = "../";
             const default_light_theme = "light";
             const default_dark_theme = "navy";
-            window.path_to_searchindex_js = "../searchindex-8c3ce0af.js";
+            window.path_to_searchindex_js = "../searchindex-4ae832c1.js";
         </script>
         <!-- Start loading toc.js asap -->
         <script src="../toc-6f3f265e.js"></script>

docs/developer_guide/cross_compilation.html

@@ -35,7 +35,7 @@
             const path_to_root = "../";
             const default_light_theme = "light";
             const default_dark_theme = "navy";
-            window.path_to_searchindex_js = "../searchindex-8c3ce0af.js";
+            window.path_to_searchindex_js = "../searchindex-4ae832c1.js";
         </script>
         <!-- Start loading toc.js asap -->
         <script src="../toc-6f3f265e.js"></script>

docs/developer_guide/target.html

@@ -35,7 +35,7 @@
             const path_to_root = "../";
             const default_light_theme = "light";
             const default_dark_theme = "navy";
-            window.path_to_searchindex_js = "../searchindex-8c3ce0af.js";
+            window.path_to_searchindex_js = "../searchindex-4ae832c1.js";
         </script>
         <!-- Start loading toc.js asap -->
         <script src="../toc-6f3f265e.js"></script>

docs/developer_guide/testing.html

@@ -35,7 +35,7 @@
             const path_to_root = "../";
             const default_light_theme = "light";
             const default_dark_theme = "navy";
-            window.path_to_searchindex_js = "../searchindex-8c3ce0af.js";
+            window.path_to_searchindex_js = "../searchindex-4ae832c1.js";
         </script>
         <!-- Start loading toc.js asap -->
         <script src="../toc-6f3f265e.js"></script>

docs/faq.html

@@ -35,7 +35,7 @@
             const path_to_root = "";
             const default_light_theme = "light";
             const default_dark_theme = "navy";
-            window.path_to_searchindex_js = "searchindex-8c3ce0af.js";
+            window.path_to_searchindex_js = "searchindex-4ae832c1.js";
         </script>
         <!-- Start loading toc.js asap -->
         <script src="toc-6f3f265e.js"></script>

docs/index.html

@@ -35,7 +35,7 @@
             const path_to_root = "";
             const default_light_theme = "light";
             const default_dark_theme = "navy";
-            window.path_to_searchindex_js = "searchindex-8c3ce0af.js";
+            window.path_to_searchindex_js = "searchindex-4ae832c1.js";
         </script>
         <!-- Start loading toc.js asap -->
         <script src="toc-6f3f265e.js"></script>

docs/print.html

@@ -36,7 +36,7 @@
             const path_to_root = "";
             const default_light_theme = "light";
             const default_dark_theme = "navy";
-            window.path_to_searchindex_js = "searchindex-8c3ce0af.js";
+            window.path_to_searchindex_js = "searchindex-4ae832c1.js";
         </script>
         <!-- Start loading toc.js asap -->
         <script src="toc-6f3f265e.js"></script>
@@ -188,7 +188,7 @@
 <p>This <a href="https://github.com/rust-lang/mdBook">mdBook</a> documents the revive Solidity compiler project. The content is found under <code>book/</code>. Run <code>make book</code> to observe changes.</p>
 <div style="break-before: page; page-break-before: always;"></div>
 <h1 id="resolc-user-guide"><a class="header" href="#resolc-user-guide"><code>resolc</code> user guide</a></h1>
-<p><code>resolc</code> is a Solidity <code>v0.8</code> compiler for <a href="https://docs.polkadot.com/develop/smart-contracts/overview/#native-smart-contracts">Polkadot <code>native</code> smart contracts</a>. Solidity compiled with <code>resolc</code> executes orders of magnitude faster than the EVM. <code>resolc</code>  also supports almost all Solidity <code>v0.8</code> features including inline assembly, offering a high level of comptability with the Ethereum Solidity reference implementation.</p>
+<p><code>resolc</code> is a Solidity <code>v0.8</code> compiler for <a href="https://docs.polkadot.com/develop/smart-contracts/overview/#native-smart-contracts">Polkadot <code>native</code> smart contracts</a>. Solidity compiled with <code>resolc</code> targets PolaVM (PVM). Thanks to additional compiler optimizations and the PVM JIT, contract code can execute much faster than the EVM equivalent. <code>resolc</code>  supports almost all Solidity <code>v0.8</code> features including inline assembly, offering a high level of comptability with the Ethereum Solidity reference implementation.</p>
 <h2 id="revive-vs-resolc-nomenclature"><a class="header" href="#revive-vs-resolc-nomenclature"><code>revive</code> vs. <code>resolc</code> nomenclature</a></h2>
 <p><code>revive</code> is the name of the overarching “Solidity to PolkaVM” compiler project, which contains multiple components (for example the Yul parser, the code generation library, the <code>resolc</code> executable itself, and many more things).</p>
 <p><code>resolc</code> is the name of the compiler driver executable, combining many <code>revive</code> components in a single and easy to use binary application.</p>
@@ -377,7 +377,7 @@ Therefore, in EVM terminology, the deploy code equals the runtime code.</p>
 <h3 id="mload-mstore-msize-mcopy-memory-related-functions"><a class="header" href="#mload-mstore-msize-mcopy-memory-related-functions"><code>mload</code>, <code>mstore</code>, <code>msize</code>, <code>mcopy</code> (memory related functions)</a></h3>
 <p>In general, revive preserves the memory layout, meaning low level memory operations are supported. However, a few caveats apply:</p>
 <ul>
-<li>The EVM linear heap memory is emulated using a fixed byte buffer of 64kb. This implies that the maximum memory a contract can use is limited to 64kbit (on Ethereum, contract memory is capped by gas and therefore varies).</li>
+<li>The EVM linear heap memory is emulated using a fixed byte buffer of 128kb. This implies that the maximum memory a contract can use is limited to 128kb (on Ethereum, contract memory is capped by gas and therefore varies).</li>
 <li>Thus, accessing memory offsets larger than the fixed buffer size will trap the contract at runtime with an <code>OutOfBound</code> error.</li>
 <li>The compiler might detect and optimize unused memory reads and writes, leading to a different <code>msize</code> compared to what the EVM would see.</li>
 </ul>
@@ -397,7 +397,7 @@ The hash is always of constant size.
 Thus, <code>revive</code> is able to supply the expected code hash and constructor arguments pointer to the runtime.</p>
 <blockquote class="blockquote-tag blockquote-tag-warning">
 <p class="blockquote-tag-title"><svg viewbox="0 0 16 16" width="18" height="18"><path d="M6.457 1.047c.659-1.234 2.427-1.234 3.086 0l6.082 11.378A1.75 1.75 0 0 1 14.082 15H1.918a1.75 1.75 0 0 1-1.543-2.575Zm1.763.707a.25.25 0 0 0-.44 0L1.698 13.132a.25.25 0 0 0 .22.368h12.164a.25.25 0 0 0 .22-.368Zm.53 3.996v2.5a.75.75 0 0 1-1.5 0v-2.5a.75.75 0 0 1 1.5 0ZM9 11a1 1 0 1 1-2 0 1 1 0 0 1 2 0Z"></path></svg>Warning</p>
-<p>This might fall apart in code creating contracts inside <code>assembly</code> blocks. <strong>We strongly discourage using the <code>create</code> family opcodes to manually craft deployments in <code>assembly</code> blocks!</strong> Usually, the reason for using <code>assembly</code> blocks is to save gas, which is futile on revive anyways due to lower transaction costs.</p>
+<p>This might fall apart in code creating contracts inside <code>assembly</code> blocks. <strong>We strongly discourage using the <code>create</code> family opcodes to manually craft deployments in <code>assembly</code> blocks!</strong> Usually, the reason for using <code>assembly</code> blocks is to save gas, which is likely futile on revive due to the underlying differences in the VM architectures, gas models and transaction costs.</p>
 </blockquote>
 <h3 id="dataoffset"><a class="header" href="#dataoffset"><code>dataoffset</code></a></h3>
 <p>Returns the contract hash.</p>
@@ -412,6 +412,32 @@ Thus, <code>revive</code> is able to supply the expected code hash and construct
 <h2 id="difference-regarding-the-solc-via-ir-mode"><a class="header" href="#difference-regarding-the-solc-via-ir-mode">Difference regarding the <code>solc</code> <code>via-ir</code> mode</a></h2>
 <p>There are two different compilation pipelines available in <code>solc</code> and <a href="https://docs.soliditylang.org/en/latest/ir-breaking-changes.html">there are small differences between them</a>.</p>
 <p>Since <code>resolc</code> processes the YUL IR, always assume the <code>solc</code> IR based codegen behavior for contracts compiled with the <code>revive</code> compiler.</p>
+<h3 id="example-state-variable-initialization-order-in-inheritance"><a class="header" href="#example-state-variable-initialization-order-in-inheritance">Example: State variable initialization order in inheritance</a></h3>
+<p>With <code>via-ir</code>, base constructors run before derived state variables are initialized:</p>
+<pre><code class="language-solidity">contract InnerContract {
+    uint public innerConstructedStartTokenId;
+
+    constructor() {
+        innerConstructedStartTokenId = _startTokenId();
+    }
+
+    function _startTokenId() internal view virtual returns (uint) {
+        return 0;
+    }
+}
+
+contract Test is InnerContract {
+    uint public START_TOKEN_ID = 1;
+
+    constructor() InnerContract() {
+    }
+
+    function _startTokenId() internal view virtual override returns (uint) {
+        return START_TOKEN_ID;
+    }
+}
+</code></pre>
+<p>Here, <code>innerConstructedStartTokenId</code> in <code>Test</code> returns <code>0</code> (with legacy EVM codegen it’d return <code>1</code>).</p>
 <div style="break-before: page; page-break-before: always;"></div>
 <h1 id="rust-contract-libraries"><a class="header" href="#rust-contract-libraries">Rust contract libraries</a></h1>
 <blockquote class="blockquote-tag blockquote-tag-note">
@@ -651,8 +677,8 @@ make test-wasm
 <h2 id="is-resolc-a-drop-in-replacement-for-solc"><a class="header" href="#is-resolc-a-drop-in-replacement-for-solc">Is <code>resolc</code> a drop-in replacement for <code>solc</code>?</a></h2>
 <p>No. <code>resolc</code> aims to work similarly to <code>solc</code>, but it’s not considered a drop-in replacement.</p>
 <div style="break-before: page; page-break-before: always;"></div>
-<h1 id="roadmap-and-vision"><a class="header" href="#roadmap-and-vision">Roadmap and Vision</a></h1>
-<p>The <code>revive</code> compiler speeds up Solidity contracts by orders of magnitude. <code>revive</code> provides a decisive edge over other contract platforms. Notably, the compiler eliminates the need of rewriting Solidity dApps as single dApp parachains for scaling reasons. Retaining as high compatibility with Ethereum Solidity as possible keeps entry barriers low.</p>
+<h1 id="vision-and-roadmap"><a class="header" href="#vision-and-roadmap">Vision and Roadmap</a></h1>
+<p>The <code>revive</code> compiler speeds up Solidity contracts significantly. <code>revive</code> provides a decisive edge over other contract platforms. Notably, the compiler eliminates the need of rewriting Solidity dApps in Rust or even as single dApp parachains for scaling reasons. Retaining as high compatibility with Ethereum Solidity as possible keeps entry barriers low.</p>
 <p>We believe in Dr. Gavin Wood’s <a href="https://gavwood.com/dappsweb3.html">ĐApps: What Web 3.0 Looks Like</a> manifesto and the ecosystem of the Solidity programming language. Our motivation lies in the realization that for a <em>true</em> web3 revolution, significant scaling efforts, like the ones provided by the PVM and this project, are necessary to unfold.</p>
 <h2 id="roadmap"><a class="header" href="#roadmap">Roadmap</a></h2>
 <p>The first major release, <code>resolc</code> v1.0.0, emits functional PVM code from given Solidity sources. It relies on <code>solc</code> and LLVM for optimizations. The main priority of this release was delivering a mostly feature complete and safe Solidity v0.8.0 compiler.</p>

docs/revive_runner.html

@@ -35,7 +35,7 @@
             const path_to_root = "";
             const default_light_theme = "light";
             const default_dark_theme = "navy";
-            window.path_to_searchindex_js = "searchindex-8c3ce0af.js";
+            window.path_to_searchindex_js = "searchindex-4ae832c1.js";
         </script>
         <!-- Start loading toc.js asap -->
         <script src="toc-6f3f265e.js"></script>

docs/roadmap.html

@@ -35,7 +35,7 @@
             const path_to_root = "";
             const default_light_theme = "light";
             const default_dark_theme = "navy";
-            window.path_to_searchindex_js = "searchindex-8c3ce0af.js";
+            window.path_to_searchindex_js = "searchindex-4ae832c1.js";
         </script>
         <!-- Start loading toc.js asap -->
         <script src="toc-6f3f265e.js"></script>
@@ -174,8 +174,8 @@
 
                 <div id="mdbook-content" class="content">
                     <main>
-                        <h1 id="roadmap-and-vision"><a class="header" href="#roadmap-and-vision">Roadmap and Vision</a></h1>
-<p>The <code>revive</code> compiler speeds up Solidity contracts by orders of magnitude. <code>revive</code> provides a decisive edge over other contract platforms. Notably, the compiler eliminates the need of rewriting Solidity dApps as single dApp parachains for scaling reasons. Retaining as high compatibility with Ethereum Solidity as possible keeps entry barriers low.</p>
+                        <h1 id="vision-and-roadmap"><a class="header" href="#vision-and-roadmap">Vision and Roadmap</a></h1>
+<p>The <code>revive</code> compiler speeds up Solidity contracts significantly. <code>revive</code> provides a decisive edge over other contract platforms. Notably, the compiler eliminates the need of rewriting Solidity dApps in Rust or even as single dApp parachains for scaling reasons. Retaining as high compatibility with Ethereum Solidity as possible keeps entry barriers low.</p>
 <p>We believe in Dr. Gavin Wood’s <a href="https://gavwood.com/dappsweb3.html">ĐApps: What Web 3.0 Looks Like</a> manifesto and the ecosystem of the Solidity programming language. Our motivation lies in the realization that for a <em>true</em> web3 revolution, significant scaling efforts, like the ones provided by the PVM and this project, are necessary to unfold.</p>
 <h2 id="roadmap"><a class="header" href="#roadmap">Roadmap</a></h2>
 <p>The first major release, <code>resolc</code> v1.0.0, emits functional PVM code from given Solidity sources. It relies on <code>solc</code> and LLVM for optimizations. The main priority of this release was delivering a mostly feature complete and safe Solidity v0.8.0 compiler.</p>

docs/searcher-c2a407aa.js

@@ -437,7 +437,7 @@ window.search = window.search || {};
         if (yes) {
             loadSearchScript(
                 window.path_to_searchindex_js ||
-                path_to_root + 'searchindex-8c3ce0af.js',
+                path_to_root + 'searchindex-4ae832c1.js',
                 'mdbook-search-index');
             search_wrap.classList.remove('hidden');
             searchicon.setAttribute('aria-expanded', 'true');

docs/searchindex-4ae832c1.js

@@ -0,0 +1 @@
+window.search = Object.assign(window.search, JSON.parse('{"doc_urls":["welcome.html#welcome","welcome.html#target-audience","welcome.html#other-polkadot-contracts-resources","welcome.html#about","user_guide.html#resolc-user-guide","user_guide.html#revive-vs-resolc-nomenclature","user_guide/installation.html#installation","user_guide/installation.html#resolc-binary-releases","user_guide/installation.html#installing-the-solc-dependency","user_guide/installation.html#revive-npm-package","user_guide/installation.html#buidling-resolc-from-source","user_guide/cli.html#cli-usage","user_guide/cli.html#llvm-optimization-levels","user_guide/cli.html#stack-size","user_guide/cli.html#heap-size","user_guide/cli.html#solc","user_guide/cli.html#debug-artifacts","user_guide/cli.html#debug-info","user_guide/cli.html#deploy-time-linking","user_guide/js.html#js-npm-package","user_guide/tooling.html#tooling-integration","user_guide/tooling.html#solidity-toolkits","user_guide/tooling.html#compiler-explorer","user_guide/tooling.html#remix-ide","user_guide/std_json.html#standard-json-interface","user_guide/std_json.html#the-settingspolkavm-object","user_guide/std_json.html#settingspolkavmdebuginformation","user_guide/std_json.html#the-settingspolkavmmemoryconfig-object","user_guide/std_json.html#the-settingsoptimizer-object","user_guide/std_json.html#settingsoptimizermode","user_guide/std_json.html#settingsllvmarguments","user_guide/differences.html#differences-to-evm","user_guide/differences.html#deploy-code-vs-runtime-code","user_guide/differences.html#solidity","user_guide/differences.html#addresscreationcode","user_guide/differences.html#yul-functions","user_guide/differences.html#mload-mstore-msize-mcopy-memory-related-functions","user_guide/differences.html#calldataload-calldatacopy","user_guide/differences.html#codecopy","user_guide/differences.html#create-create2","user_guide/differences.html#dataoffset","user_guide/differences.html#datasize","user_guide/differences.html#prevrandao-difficulty","user_guide/differences.html#pc-extcodecopy","user_guide/differences.html#blobhash-blobbasefee","user_guide/differences.html#difference-regarding-the-solc-via-ir-mode","user_guide/differences.html#example-state-variable-initialization-order-in-inheritance","user_guide/rust_libraries.html#rust-contract-libraries","revive_runner.html#revive-runner-sandbox","revive_runner.html#installation-and-usage","revive_runner.html#trace-logs","revive_runner.html#automatic-contract-instantiation","revive_runner.html#example","developer_guide.html#developer-guide","developer_guide/contributing.html#contributor-guide","developer_guide/contributing.html#getting-started","developer_guide/contributing.html#using-the-makefile","developer_guide/contributing.html#codebase-organization","developer_guide/contributing.html#contribution-rules","developer_guide/contributing.html#style-guide","developer_guide/contributing.html#ai-policy","developer_guide/architecture.html#compiler-architecture-and-internals","developer_guide/architecture.html#resolc","developer_guide/architecture.html#reproducible-contract-builds","developer_guide/architecture.html#the-revive-compiler-libraries","developer_guide/architecture.html#evm-heap-memory","developer_guide/architecture.html#the-llvm-dependency","developer_guide/architecture.html#custom-optimizations","developer_guide/target.html#pvm-and-the-pallet-revive-runtime-target","developer_guide/target.html#target-cpu-configuration","developer_guide/target.html#why-pvm","developer_guide/target.html#host-environment-pallet-revive","developer_guide/testing.html#testing-strategy","developer_guide/testing.html#bug-compatibility-with-ethereum-solidity","developer_guide/testing.html#differential-integration-tests","developer_guide/testing.html#the-differential-testing-utility","developer_guide/cross_compilation.html#cross-compilation","developer_guide/cross_compilation.html#wasm-via-emscripten","developer_guide/cross_compilation.html#musl-libc","faq.html#faq","faq.html#what-evm-version-do-you-support","faq.html#is-inline-assembly-supported","faq.html#do-you-support-opcode-xy","faq.html#in-what-solidity-version-should-i-write-my-dapp","faq.html#tool-xy-says-the-contract-size-is-larger-than-24kb-and-will-fail-to-deploy","faq.html#is-resolc-a-drop-in-replacement-for-solc","roadmap.html#vision-and-roadmap","roadmap.html#roadmap"],"index":{"documentStore":{"docInfo":{"0":{"body":7,"breadcrumbs":2,"title":1},"1":{"body":22,"breadcrumbs":3,"title":2},"10":{"body":6,"breadcrumbs":7,"title":3},"11":{"body":33,"breadcrumbs":8,"title":2},"12":{"body":53,"breadcrumbs":9,"title":3},"13":{"body":62,"breadcrumbs":8,"title":2},"14":{"body":75,"breadcrumbs":8,"title":2},"15":{"body":10,"breadcrumbs":7,"title":1},"16":{"body":26,"breadcrumbs":8,"title":2},"17":{"body":15,"breadcrumbs":8,"title":2},"18":{"body":236,"breadcrumbs":9,"title":3},"19":{"body":31,"breadcrumbs":9,"title":3},"2":{"body":7,"breadcrumbs":4,"title":3},"20":{"body":9,"breadcrumbs":Line truncated

docs/searchindex-8c3ce0af.js

@@ -1 +0,0 @@
-window.search = Object.assign(window.search, JSON.parse('{"doc_urls":["welcome.html#welcome","welcome.html#target-audience","welcome.html#other-polkadot-contracts-resources","welcome.html#about","user_guide.html#resolc-user-guide","user_guide.html#revive-vs-resolc-nomenclature","user_guide/installation.html#installation","user_guide/installation.html#resolc-binary-releases","user_guide/installation.html#installing-the-solc-dependency","user_guide/installation.html#revive-npm-package","user_guide/installation.html#buidling-resolc-from-source","user_guide/cli.html#cli-usage","user_guide/cli.html#llvm-optimization-levels","user_guide/cli.html#stack-size","user_guide/cli.html#heap-size","user_guide/cli.html#solc","user_guide/cli.html#debug-artifacts","user_guide/cli.html#debug-info","user_guide/cli.html#deploy-time-linking","user_guide/js.html#js-npm-package","user_guide/tooling.html#tooling-integration","user_guide/tooling.html#solidity-toolkits","user_guide/tooling.html#compiler-explorer","user_guide/tooling.html#remix-ide","user_guide/std_json.html#standard-json-interface","user_guide/std_json.html#the-settingspolkavm-object","user_guide/std_json.html#settingspolkavmdebuginformation","user_guide/std_json.html#the-settingspolkavmmemoryconfig-object","user_guide/std_json.html#the-settingsoptimizer-object","user_guide/std_json.html#settingsoptimizermode","user_guide/std_json.html#settingsllvmarguments","user_guide/differences.html#differences-to-evm","user_guide/differences.html#deploy-code-vs-runtime-code","user_guide/differences.html#solidity","user_guide/differences.html#addresscreationcode","user_guide/differences.html#yul-functions","user_guide/differences.html#mload-mstore-msize-mcopy-memory-related-functions","user_guide/differences.html#calldataload-calldatacopy","user_guide/differences.html#codecopy","user_guide/differences.html#create-create2","user_guide/differences.html#dataoffset","user_guide/differences.html#datasize","user_guide/differences.html#prevrandao-difficulty","user_guide/differences.html#pc-extcodecopy","user_guide/differences.html#blobhash-blobbasefee","user_guide/differences.html#difference-regarding-the-solc-via-ir-mode","user_guide/rust_libraries.html#rust-contract-libraries","revive_runner.html#revive-runner-sandbox","revive_runner.html#installation-and-usage","revive_runner.html#trace-logs","revive_runner.html#automatic-contract-instantiation","revive_runner.html#example","developer_guide.html#developer-guide","developer_guide/contributing.html#contributor-guide","developer_guide/contributing.html#getting-started","developer_guide/contributing.html#using-the-makefile","developer_guide/contributing.html#codebase-organization","developer_guide/contributing.html#contribution-rules","developer_guide/contributing.html#style-guide","developer_guide/contributing.html#ai-policy","developer_guide/architecture.html#compiler-architecture-and-internals","developer_guide/architecture.html#resolc","developer_guide/architecture.html#reproducible-contract-builds","developer_guide/architecture.html#the-revive-compiler-libraries","developer_guide/architecture.html#evm-heap-memory","developer_guide/architecture.html#the-llvm-dependency","developer_guide/architecture.html#custom-optimizations","developer_guide/target.html#pvm-and-the-pallet-revive-runtime-target","developer_guide/target.html#target-cpu-configuration","developer_guide/target.html#why-pvm","developer_guide/target.html#host-environment-pallet-revive","developer_guide/testing.html#testing-strategy","developer_guide/testing.html#bug-compatibility-with-ethereum-solidity","developer_guide/testing.html#differential-integration-tests","developer_guide/testing.html#the-differential-testing-utility","developer_guide/cross_compilation.html#cross-compilation","developer_guide/cross_compilation.html#wasm-via-emscripten","developer_guide/cross_compilation.html#musl-libc","faq.html#faq","faq.html#what-evm-version-do-you-support","faq.html#is-inline-assembly-supported","faq.html#do-you-support-opcode-xy","faq.html#in-what-solidity-version-should-i-write-my-dapp","faq.html#tool-xy-says-the-contract-size-is-larger-than-24kb-and-will-fail-to-deploy","faq.html#is-resolc-a-drop-in-replacement-for-solc","roadmap.html#roadmap-and-vision","roadmap.html#roadmap"],"index":{"documentStore":{"docInfo":{"0":{"body":7,"breadcrumbs":2,"title":1},"1":{"body":22,"breadcrumbs":3,"title":2},"10":{"body":6,"breadcrumbs":7,"title":3},"11":{"body":33,"breadcrumbs":8,"title":2},"12":{"body":53,"breadcrumbs":9,"title":3},"13":{"body":62,"breadcrumbs":8,"title":2},"14":{"body":75,"breadcrumbs":8,"title":2},"15":{"body":10,"breadcrumbs":7,"title":1},"16":{"body":26,"breadcrumbs":8,"title":2},"17":{"body":15,"breadcrumbs":8,"title":2},"18":{"body":236,"breadcrumbs":9,"title":3},"19":{"body":31,"breadcrumbs":9,"title":3},"2":{"body":7,"breadcrumbs":4,"title":3},"20":{"body":9,"breadcrumbs":7,"title":2},"21":{"body":14,"breadcrumbs":7,"title":2},"22":{"body":11,"breadcrumbs":7,"Line truncated

docs/user_guide.html

@@ -35,7 +35,7 @@
             const path_to_root = "";
             const default_light_theme = "light";
             const default_dark_theme = "navy";
-            window.path_to_searchindex_js = "searchindex-8c3ce0af.js";
+            window.path_to_searchindex_js = "searchindex-4ae832c1.js";
         </script>
         <!-- Start loading toc.js asap -->
         <script src="toc-6f3f265e.js"></script>
@@ -175,7 +175,7 @@
                 <div id="mdbook-content" class="content">
                     <main>
                         <h1 id="resolc-user-guide"><a class="header" href="#resolc-user-guide"><code>resolc</code> user guide</a></h1>
-<p><code>resolc</code> is a Solidity <code>v0.8</code> compiler for <a href="https://docs.polkadot.com/develop/smart-contracts/overview/#native-smart-contracts">Polkadot <code>native</code> smart contracts</a>. Solidity compiled with <code>resolc</code> executes orders of magnitude faster than the EVM. <code>resolc</code>  also supports almost all Solidity <code>v0.8</code> features including inline assembly, offering a high level of comptability with the Ethereum Solidity reference implementation.</p>
+<p><code>resolc</code> is a Solidity <code>v0.8</code> compiler for <a href="https://docs.polkadot.com/develop/smart-contracts/overview/#native-smart-contracts">Polkadot <code>native</code> smart contracts</a>. Solidity compiled with <code>resolc</code> targets PolaVM (PVM). Thanks to additional compiler optimizations and the PVM JIT, contract code can execute much faster than the EVM equivalent. <code>resolc</code>  supports almost all Solidity <code>v0.8</code> features including inline assembly, offering a high level of comptability with the Ethereum Solidity reference implementation.</p>
 <h2 id="revive-vs-resolc-nomenclature"><a class="header" href="#revive-vs-resolc-nomenclature"><code>revive</code> vs. <code>resolc</code> nomenclature</a></h2>
 <p><code>revive</code> is the name of the overarching “Solidity to PolkaVM” compiler project, which contains multiple components (for example the Yul parser, the code generation library, the <code>resolc</code> executable itself, and many more things).</p>
 <p><code>resolc</code> is the name of the compiler driver executable, combining many <code>revive</code> components in a single and easy to use binary application.</p>

docs/user_guide/cli.html

@@ -35,7 +35,7 @@
             const path_to_root = "../";
             const default_light_theme = "light";
             const default_dark_theme = "navy";
-            window.path_to_searchindex_js = "../searchindex-8c3ce0af.js";
+            window.path_to_searchindex_js = "../searchindex-4ae832c1.js";
         </script>
         <!-- Start loading toc.js asap -->
         <script src="../toc-6f3f265e.js"></script>

docs/user_guide/differences.html

@@ -35,7 +35,7 @@
             const path_to_root = "../";
             const default_light_theme = "light";
             const default_dark_theme = "navy";
-            window.path_to_searchindex_js = "../searchindex-8c3ce0af.js";
+            window.path_to_searchindex_js = "../searchindex-4ae832c1.js";
         </script>
         <!-- Start loading toc.js asap -->
         <script src="../toc-6f3f265e.js"></script>
@@ -199,7 +199,7 @@ Therefore, in EVM terminology, the deploy code equals the runtime code.</p>
 <h3 id="mload-mstore-msize-mcopy-memory-related-functions"><a class="header" href="#mload-mstore-msize-mcopy-memory-related-functions"><code>mload</code>, <code>mstore</code>, <code>msize</code>, <code>mcopy</code> (memory related functions)</a></h3>
 <p>In general, revive preserves the memory layout, meaning low level memory operations are supported. However, a few caveats apply:</p>
 <ul>
-<li>The EVM linear heap memory is emulated using a fixed byte buffer of 64kb. This implies that the maximum memory a contract can use is limited to 64kbit (on Ethereum, contract memory is capped by gas and therefore varies).</li>
+<li>The EVM linear heap memory is emulated using a fixed byte buffer of 128kb. This implies that the maximum memory a contract can use is limited to 128kb (on Ethereum, contract memory is capped by gas and therefore varies).</li>
 <li>Thus, accessing memory offsets larger than the fixed buffer size will trap the contract at runtime with an <code>OutOfBound</code> error.</li>
 <li>The compiler might detect and optimize unused memory reads and writes, leading to a different <code>msize</code> compared to what the EVM would see.</li>
 </ul>
@@ -219,7 +219,7 @@ The hash is always of constant size.
 Thus, <code>revive</code> is able to supply the expected code hash and constructor arguments pointer to the runtime.</p>
 <blockquote class="blockquote-tag blockquote-tag-warning">
 <p class="blockquote-tag-title"><svg viewbox="0 0 16 16" width="18" height="18"><path d="M6.457 1.047c.659-1.234 2.427-1.234 3.086 0l6.082 11.378A1.75 1.75 0 0 1 14.082 15H1.918a1.75 1.75 0 0 1-1.543-2.575Zm1.763.707a.25.25 0 0 0-.44 0L1.698 13.132a.25.25 0 0 0 .22.368h12.164a.25.25 0 0 0 .22-.368Zm.53 3.996v2.5a.75.75 0 0 1-1.5 0v-2.5a.75.75 0 0 1 1.5 0ZM9 11a1 1 0 1 1-2 0 1 1 0 0 1 2 0Z"></path></svg>Warning</p>
-<p>This might fall apart in code creating contracts inside <code>assembly</code> blocks. <strong>We strongly discourage using the <code>create</code> family opcodes to manually craft deployments in <code>assembly</code> blocks!</strong> Usually, the reason for using <code>assembly</code> blocks is to save gas, which is futile on revive anyways due to lower transaction costs.</p>
+<p>This might fall apart in code creating contracts inside <code>assembly</code> blocks. <strong>We strongly discourage using the <code>create</code> family opcodes to manually craft deployments in <code>assembly</code> blocks!</strong> Usually, the reason for using <code>assembly</code> blocks is to save gas, which is likely futile on revive due to the underlying differences in the VM architectures, gas models and transaction costs.</p>
 </blockquote>
 <h3 id="dataoffset"><a class="header" href="#dataoffset"><code>dataoffset</code></a></h3>
 <p>Returns the contract hash.</p>
@@ -234,6 +234,32 @@ Thus, <code>revive</code> is able to supply the expected code hash and construct
 <h2 id="difference-regarding-the-solc-via-ir-mode"><a class="header" href="#difference-regarding-the-solc-via-ir-mode">Difference regarding the <code>solc</code> <code>via-ir</code> mode</a></h2>
 <p>There are two different compilation pipelines available in <code>solc</code> and <a href="https://docs.soliditylang.org/en/latest/ir-breaking-changes.html">there are small differences between them</a>.</p>
 <p>Since <code>resolc</code> processes the YUL IR, always assume the <code>solc</code> IR based codegen behavior for contracts compiled with the <code>revive</code> compiler.</p>
+<h3 id="example-state-variable-initialization-order-in-inheritance"><a class="header" href="#example-state-variable-initialization-order-in-inheritance">Example: State variable initialization order in inheritance</a></h3>
+<p>With <code>via-ir</code>, base constructors run before derived state variables are initialized:</p>
+<pre><code class="language-solidity">contract InnerContract {
+    uint public innerConstructedStartTokenId;
+
+    constructor() {
+        innerConstructedStartTokenId = _startTokenId();
+    }
+
+    function _startTokenId() internal view virtual returns (uint) {
+        return 0;
+    }
+}
+
+contract Test is InnerContract {
+    uint public START_TOKEN_ID = 1;
+
+    constructor() InnerContract() {
+    }
+
+    function _startTokenId() internal view virtual override returns (uint) {
+        return START_TOKEN_ID;
+    }
+}
+</code></pre>
+<p>Here, <code>innerConstructedStartTokenId</code> in <code>Test</code> returns <code>0</code> (with legacy EVM codegen it’d return <code>1</code>).</p>
 
                     </main>
 

docs/user_guide/installation.html

@@ -35,7 +35,7 @@
             const path_to_root = "../";
             const default_light_theme = "light";
             const default_dark_theme = "navy";
-            window.path_to_searchindex_js = "../searchindex-8c3ce0af.js";
+            window.path_to_searchindex_js = "../searchindex-4ae832c1.js";
         </script>
         <!-- Start loading toc.js asap -->
         <script src="../toc-6f3f265e.js"></script>

docs/user_guide/js.html

@@ -35,7 +35,7 @@
             const path_to_root = "../";
             const default_light_theme = "light";
             const default_dark_theme = "navy";
-            window.path_to_searchindex_js = "../searchindex-8c3ce0af.js";
+            window.path_to_searchindex_js = "../searchindex-4ae832c1.js";
         </script>
         <!-- Start loading toc.js asap -->
         <script src="../toc-6f3f265e.js"></script>

docs/user_guide/rust_libraries.html

@@ -35,7 +35,7 @@
             const path_to_root = "../";
             const default_light_theme = "light";
             const default_dark_theme = "navy";
-            window.path_to_searchindex_js = "../searchindex-8c3ce0af.js";
+            window.path_to_searchindex_js = "../searchindex-4ae832c1.js";
         </script>
         <!-- Start loading toc.js asap -->
         <script src="../toc-6f3f265e.js"></script>

docs/user_guide/std_json.html

@@ -35,7 +35,7 @@
             const path_to_root = "../";
             const default_light_theme = "light";
             const default_dark_theme = "navy";
-            window.path_to_searchindex_js = "../searchindex-8c3ce0af.js";
+            window.path_to_searchindex_js = "../searchindex-4ae832c1.js";
         </script>
         <!-- Start loading toc.js asap -->
         <script src="../toc-6f3f265e.js"></script>

docs/user_guide/tooling.html

@@ -35,7 +35,7 @@
             const path_to_root = "../";
             const default_light_theme = "light";
             const default_dark_theme = "navy";
-            window.path_to_searchindex_js = "../searchindex-8c3ce0af.js";
+            window.path_to_searchindex_js = "../searchindex-4ae832c1.js";
         </script>
         <!-- Start loading toc.js asap -->
         <script src="../toc-6f3f265e.js"></script>

docs/welcome.html

@@ -35,7 +35,7 @@
             const path_to_root = "";
             const default_light_theme = "light";
             const default_dark_theme = "navy";
-            window.path_to_searchindex_js = "searchindex-8c3ce0af.js";
+            window.path_to_searchindex_js = "searchindex-4ae832c1.js";
         </script>
         <!-- Start loading toc.js asap -->
         <script src="toc-6f3f265e.js"></script>