Fix CI (#2420)

* Clean up code

* Update changelog

* Fix `account_id` host fn call

* Update fixtures

* Fix tests

* Increase partition size

* Fix tests

* Fix features

* Fix tests

* Increase partition count

* Restructure testing for dry-run errors

* Update `Cargo.lock`

* Fix tests, update architecture docs

Author: cmichi

.github/workflows/ci.yml

@@ -451,8 +451,51 @@ jobs:
           # at the same time, hence we use this workaround.
           QUICKCHECK_TESTS:            0
         run: |
-          cargo +nightly nextest run --all-features --no-fail-fast --workspace --locked
-          cargo +nightly test --all-features --no-fail-fast --workspace --doc --locked
+          cargo +nightly nextest run --all-features --no-fail-fast --workspace --locked --jobs 3
+
+  test-docs:
+      runs-on: ubuntu-latest
+      needs: [set-image, check]
+      defaults:
+          run:
+              shell: bash
+      container:
+          image: ${{ needs.set-image.outputs.IMAGE }}
+      strategy:
+          fail-fast: false
+          matrix:
+              workspace: [ink, linting]
+      steps:
+          - name: Checkout
+            uses: actions/checkout@v4
+            with:
+                fetch-depth: 1
+
+          - name: Cache
+            uses: Swatinem/rust-cache@f0deed1e0edfc6a9be95417288c0e1099b1eeec3 # v2.7.7
+            with:
+                cache-directories: |
+                    ${{ env.CARGO_TARGET_DIR }}
+
+          - name: Rust Info
+            uses: ./.github/rust-info
+
+          - name: Test
+            if: ${{ matrix.workspace == 'ink' }}
+            env:
+                # Setting incremental = 0 to reduce compilation artifact size.
+                # The CI otherwise fails with "no disk space"
+                # todo Remove again at one point. This is a speed trade-off.
+                CARGO_INCREMENTAL: 0
+                # Fix for linking of `linkme` for `cargo test`: https://github.com/dtolnay/linkme/issues/49
+                RUSTFLAGS: -Clink-dead-code -Clink-arg=-z -Clink-arg=nostart-stop-gc
+                # Since we run the tests with `--all-features` this implies the feature
+                # `ink-fuzz-tests` as well -- i.e. the fuzz tests are run.
+                # There's no way to disable a single feature while enabling all features
+                # at the same time, hence we use this workaround.
+                QUICKCHECK_TESTS:            0
+            run: |
+                cargo +nightly test --all-features --no-fail-fast --workspace --doc --locked
 
   test-linting:
       runs-on: ubuntu-latest
@@ -602,7 +645,7 @@ jobs:
     strategy:
       fail-fast: false
       matrix:
-        partition: [1, 2, 3, 4, 5, 6]
+        partition: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]
     steps:
       - name: Checkout
         uses: actions/checkout@v4
@@ -620,9 +663,9 @@ jobs:
             # Fix for linking of `linkme` for `cargo test`: https://github.com/dtolnay/linkme/issues/49
             RUSTFLAGS: -Clink-arg=-z -Clink-arg=nostart-stop-gc -Clink-dead-code
         with:
-          # run all tests with --all-features, which will run the e2e-tests feature if present
+          # Run all tests with --all-features, which will run the `e2e-tests` feature if present.
           args:
-            /bin/bash -c "scripts/for_all_contracts_exec.sh --path integration-tests --ignore internal/static-buffer --ignore internal/mapping --partition ${{ matrix.partition }}/6 -- \
+            /bin/bash -c "scripts/for_all_contracts_exec.sh --path integration-tests --ignore internal/static-buffer --ignore internal/mapping --partition ${{ matrix.partition }}/16 -- \
                 cargo +nightly test --all-features --all --manifest-path {}"
 
   examples-test-mapping:

.github/workflows/issue-notifier.yml

@@ -17,15 +17,12 @@ jobs:
           - awesome-ink
           - cargo-contract
           - contracts-ui
+          - docker-images
           - ink
           - ink-docs
           - ink-examples
-          - ink-waterfall
           - ink-workshop
           - link
-          - nft-marketplace-demo
-          - pallet-contracts-xcm
-          - smart-bench
           - squink-splash-advanced
           - squink-splash-beginner
           - substrate-contracts-node

.images/pallet-contracts.png

@@ -1,12 +1,10 @@
 # ink!ternals
 
-todo: rework this doc
-
 This document describes the architecture of ink!. The information
 here targets those who want to understand or modify the inner
 workings of this project.
 
-In general we treat documentation as a first-class citizen.
+In general, we treat documentation as a first-class citizen.
 All crates mentioned below should be documented really well.
 You can find the crate documentation on docs.rs or for our
 `master` branch under GitHub pages. So for `ink` e.g.:
@@ -30,7 +28,7 @@ ink! is composed of a number of crates that are all found in the
     This includes getting and setting a smart contracts storage, as well
     as the mentioned environmental functions.
 * [`metadata`](https://github.com/use-ink/ink/tree/master/crates/metadata):
-  Describes the contract in a platform agnostic way, i.e. its interface
+  Describes the contract in a platform-agnostic way, i.e. its interface
   and the types, its storage layout, etc.
 * [`prelude`](https://github.com/use-ink/ink/tree/master/crates/prelude):
   Provides an interface to typical standard library types and
@@ -57,12 +55,19 @@ a `no_std` environment.
 Exceptions are `metadata` and `engine`, which cover use-cases that
 are only relevant off-chain.
 
-ink! contracts are compiled for a WebAssembly (Wasm) target architecture,
-i.e. they are executed in a Wasm sandbox execution environment on the
-blockchain itself ‒ hence a `no_std` environment.
-More specifically they are executed by the [`pallet-revive`](https://github.com/paritytech/substrate/tree/master/frame/contracts),
-a module of the Substrate blockchain framework. This module takes ink!
-smart contracts and runs them in a sandbox environment.
+ink! contracts are compiled to RISC-V bytecode for
+[the PolkaVM interpreter](https://github.com/paritytech/polkavm).
+This is how ink! smart contracts are executed on a blockchain:
+they are uploaded to a blockchain that runs PolkaVM, PolkaVM then
+interprets them.
+As contracts are executed in a sandbox execution environment on the
+blockchain itself we compile them to a `no_std` environment.
+More specifically they are executed by the [`pallet-revive`](https://github.com/paritytech/substrate/tree/master/frame/revive),
+a module of the Polkadot SDK blockchain framework. This module takes ink!
+smart contracts and runs them in a PolkaVM sandbox environment.
+It also provides an API to smart contracts for anything a smart contract
+needs: storing + retrieving data, calling other contracts, sending value,
+fetching the block number, ….
 
 ## Overview
 
@@ -72,24 +77,49 @@ The above diagram shows the main components of the ink! language
 and how they interact. This pipeline is run once you execute
 `cargo build` on an ink! smart contract.
 
-The central delegating crate for the ink! eDSL is `ink`.
+The central umbrella crate for the ink! eDSL is `ink`.
 
 In the `crates/ink/` folder you'll find three separate
 crates on which `ink` relies heavily:
 
 * `ink_macro`: The procedural macros, they take code annotated with e.g.
-   `[ink::contract]` and forwards it to `ink_ir`.
-* `ink_ir`: Defines everything the procedural macro needs in order to
-   parse, analyze and generate code for ink! smart contracts.
+   `[ink::contract]` and forward it to `ink_ir`.
+* `ink_ir`: The ink! Intermediate Representation (IR). Defines everything
+   the procedural macro needs in order to parse, analyze and generate code
+   for ink! smart contracts.
 * `ink_codegen`: Generates Rust code from the ink! IR.
 
+The `cargo-expand` tool can be used to display the Rust source code that
+`ink_codegen` generates for an ink! contract:
+
+```ignore
+cd ink/integration-tests/public/flipper/
+cargo expand --no-default-features --target riscv64gc-unknown-none-elf
+```
+
+Ideally we'd use the target JSON file from PolkaVM for the `--target`,
+but [`cargo-expand`](https://crates.io/crates/cargo-expand) doesn't
+support JSON files for this parameter at the time of writing.
+
 ## Building ink! contracts
 
 While you can build an ink! smart contract with just `cargo build`, we
 recommend using our build tool [`cargo-contract`](https://github.com/use-ink/cargo-contract).
-It automatically compiles for the correct WebAssembly target
+It automatically compiles for the correct PolkaVM target
 architecture and uses an optimal set of compiler flags.
 
+Ann approximation of the build command it will execute is:
+
+```bash
+cd ink/integration-tests/public/flipper/
+cargo +nightly build
+  --no-default-features
+  --target ~/polkavm/crates/polkavm-linker/riscv64emac-unknown-none-polkavm.json
+  -Zbuild-std="core,alloc"
+```
+
+You can also `build` or `check` a contract with this command.
+
 ## Allocator
 
 ink! smart contracts use a very simple bump allocator for dynamic
@@ -101,7 +131,9 @@ This was done with the intention of reducing its complexity, which
 would have resulted in higher costs for the user (due to increased
 gas costs) and a lower transaction throughput. Freeing memory is
 irrelevant for our use-case anyway, as the entire memory instance
-is set up fresh for each individual contract call anyway.
+is set up fresh for each individual contract call.
+
+_todo reviewed until here, below not yet_
 
 ## Unstable Rust features in ink!
 
@@ -135,7 +167,7 @@ This `pallet-revive` is the smart contracts module of
 
 The relationship is as depicted in this diagram:
 
-<img src="./.images/pallet-contracts.png" alt="pallet-revive Interaction" width="800" />
+<img src="./.images/pallet-revive.png" alt="pallet-revive Architecture" width="800" />
 
 ### Communication with the pallet
 ink! uses a static buffer for interacting with `pallet-revive`, i.e.

ARCHITECTURE.md

@@ -6,7 +6,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 [Unreleased]
 
-- Implement contract invokation in off-chain environment engine - [#1957](https://github.com/paritytech/ink/pull/1988)
+### Contract delegate can no longer be done by code
 
 ## Changed
 - Restrict which `cfg` attributes can be used ‒ [#2313](https://github.com/use-ink/ink/pull/2313)
@@ -16,6 +16,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Add feature flag to compile contracts for `pallet-revive` ‒ [#2318](https://github.com/use-ink/ink/pull/2318)
 - Support for `caller_is_root` - [#2332] (https://github.com/use-ink/ink/pull/2332)
 - Improve support for Solidity ABI calling conventions - [#2411](https://github.com/use-ink/ink/pull/2411)
+- Implement contract invocation in off-chain environment engine - [#1957](https://github.com/paritytech/ink/pull/1988)
 
 ## Fixed
 - [E2E] Have port parsing handle comma-separated list ‒ [#2336](https://github.com/use-ink/ink/pull/2336)
@@ -608,7 +609,7 @@ errors that may come from the smart contracting language itself.
 
 For example, take the case where a contract message is called using an invalid selector.
 This is not something a smart contract author should need to define as failure case, nor
-is it something that the Contracts pallet needs to be aware of.
+is it something that `pallet-revive` needs to be aware of.
 
 Previously, the contract execution would trap if an invalid selector was used, leaving
 callers with no way to handle the error gracefully. This can now be handled with the help