Merge branch 'master' into gui-fix-CI

Cargo.toml

@@ -648,7 +648,7 @@ bridge-hub-test-utils = { path = "cumulus/parachains/runtimes/bridge-hubs/test-u
 bridge-hub-westend-emulated-chain = { path = "cumulus/parachains/integration-tests/emulated/chains/parachains/bridges/bridge-hub-westend" }
 bridge-hub-westend-runtime = { path = "cumulus/parachains/runtimes/bridge-hubs/bridge-hub-westend", default-features = false }
 bridge-runtime-common = { path = "bridges/bin/runtime-common", default-features = false }
-bs58 = { version = "0.5.0", default-features = false }
+bs58 = { version = "0.5.1", default-features = false }
 build-helper = { version = "0.1.1" }
 byte-slice-cast = { version = "1.2.1", default-features = false }
 byteorder = { version = "1.3.2", default-features = false }
@@ -1176,7 +1176,7 @@ separator = { version = "0.4.1" }
 serde = { version = "1.0.204", default-features = false }
 serde-big-array = { version = "0.3.2" }
 serde_derive = { version = "1.0.117" }
-serde_json = { version = "1.0.120", default-features = false }
+serde_json = { version = "1.0.121", default-features = false }
 serde_yaml = { version = "0.9" }
 serial_test = { version = "2.0.0" }
 sha1 = { version = "0.10.6" }

cumulus/primitives/timestamp/Cargo.toml

@@ -10,9 +10,6 @@ license = "Apache-2.0"
 workspace = true
 
 [dependencies]
-codec = { features = ["derive"], workspace = true }
-futures = { workspace = true }
-
 # Substrate
 sp-inherents = { workspace = true }
 sp-timestamp = { workspace = true }
@@ -23,7 +20,6 @@ cumulus-primitives-core = { workspace = true }
 [features]
 default = ["std"]
 std = [
-	"codec/std",
 	"cumulus-primitives-core/std",
 	"sp-inherents/std",
 	"sp-timestamp/std",

docs/contributor/DOCUMENTATION_GUIDELINES.md

@@ -1,7 +1,7 @@
 # Substrate Documentation Guidelines
 
 This document is focused on documenting parts of Substrate that relate to its external API. The list of such crates can
-be found in [CODEOWNERS](./CODEOWNERS). Search for the crates auto-assigned to the `docs-audit` team.
+be found in [CODEOWNERS](/.github/CODEOWNERS). Search for the crates auto-assigned to the `docs-audit` team.
 
 These crates are used by external developers and need thorough documentation. They are the most concerned with FRAME
 development.
@@ -33,7 +33,7 @@ First, consider the case for all such crates, except for those that are pallets.
 
 The first question is, what should you document? Use this filter:
 
-1. In the crates assigned to `docs-audit` in [CODEOWNERS](./CODEOWNERS),
+1. In the crates assigned to `docs-audit` in [CODEOWNERS](/.github/CODEOWNERS),
 2. All `pub` items need to be documented. If not `pub`, it doesn't appear in the rust-docs, and is not public facing.
 
    - Within `pub` items, sometimes they are only `pub` to be used by another internal crate, and you can foresee that
@@ -88,20 +88,19 @@ sections](https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/ru
 we will most likely not need to think about panic and safety in any runtime related code. Our code is never `unsafe`,
 and will (almost) never panic.
 
-Use `# Examples as much as possible. These are great ways to further demonstrate what your APIs are doing, and add free
-test coverage. As an additional benefit, any code in rust-docs is treated as an "integration tests", not unit tests,
+Use `# Examples` as much as possible. These are great ways to further demonstrate what your APIs are doing, and add free
+test coverage. As an additional benefit, any code in rust-docs is treated as an "integration test",
 which tests your crate in a different way than unit tests. So, it is both a win for "more documentation" and a win for
 "more test coverage".
 
 You can also consider having an `# Error` section optionally. Of course, this only applies if there is a `Result` being
 returned, and if the `Error` variants are overly complicated.
 
-Strive to include correct links to other items in your written docs as much as possible. In other words, avoid
-\`some_func\` and instead use \[\`some_fund\`\]. Read more about how to correctly use links in your rust-docs
+Strive to include correct links to other items in your written docs as much as possible.
+Read more about how to correctly use links in your rust-docs
 [here](https://doc.rust-lang.org/rustdoc/write-documentation/linking-to-items-by-name.html#valid-links) and
-[here](https://rust-lang.github.io/rfcs/1946-intra-rustdoc-links.html#additions-to-the-documentation-syntax). Strive to
-include correct links to other items in your written docs as much as possible. In other words, avoid `` `some_func` ``
-and instead use ``[`some_func`]``.
+[here](https://rust-lang.github.io/rfcs/1946-intra-rustdoc-links.html#additions-to-the-documentation-syntax).
+In other words, avoid `` `some_func` `` and instead use ``[`some_func`]``.
 
 > While you are linking, you might become conscious of the fact that you are in need of linking to (too many) foreign
 items in order to explain your API. This is leaning more towards API-Design rather than documentation, but it is a
@@ -145,7 +144,7 @@ The following are a set of notes that may not necessarily hold in all circumstan
 
 You should make sure that your code is properly-named and well-organized so that your code functions as a form of
 documentation. However, within the complexity of our projects in Polkadot/Substrate that is not enough. Particularly,
-things like examples, errors and panics cannot be documented only through properly- named and well-organized code.
+things like examples, errors and panics cannot be documented only through properly-named and well-organized code.
 
 > Our north star is self-documenting code that also happens to be well-documented and littered with examples.
 
@@ -272,7 +271,7 @@ For the top-level pallet docs, consider the following template:
 //! up>
 ```
 
-This template's details (heading 3s and beyond) are left flexible, and at the discretion of the developer to make the
+This template's details (Heading 3s and beyond) are left flexible, and at the discretion of the developer to make the
 best final choice about. For example, you might want to include `### Terminology` or not. Moreover, you might find it
 more useful to include it in `## Overview`.
 

docs/sdk/Cargo.toml

@@ -40,6 +40,7 @@ frame-support = { workspace = true }
 frame-executive = { workspace = true }
 pallet-example-single-block-migrations = { workspace = true, default-features = true }
 frame-metadata-hash-extension = { workspace = true, default-features = true }
+log = { workspace = true, default-features = true }
 
 # Substrate Client
 sc-network = { workspace = true, default-features = true }
@@ -107,7 +108,11 @@ sp-version = { workspace = true, default-features = true }
 
 # XCM
 xcm = { workspace = true, default-features = true }
+xcm-builder = { workspace = true }
 xcm-docs = { workspace = true }
+xcm-executor = { workspace = true }
+xcm-simulator = { workspace = true }
+pallet-xcm = { workspace = true }
 
 # runtime guides
 chain-spec-guide-runtime = { workspace = true }

docs/sdk/src/guides/async_backing_guide.rs

@@ -27,8 +27,8 @@
 //! "scheduling_lookahead": 2
 //! ```
 //!
-//! <div class="warning">`scheduling_lookahead` must be set to 2, otherwise parachain block times
-//! will degrade to worse than with sync backing!</div>
+//! <div class="warning"><code>scheduling_lookahead</code> must be set to 2, otherwise parachain
+//! block times will degrade to worse than with sync backing!</div>
 //!
 //! ## Phase 1 - Update Parachain Runtime
 //!

docs/sdk/src/guides/enable_elastic_scaling_mvp.rs

@@ -1,7 +1,7 @@
 //! # Enable elastic scaling MVP for a parachain
 //!
 //! <div class="warning">This guide assumes full familiarity with Asynchronous Backing and its
-//! terminology, as defined in https://wiki.polkadot.network/docs/maintain-guides-async-backing.
+//! terminology, as defined in <a href="https://wiki.polkadot.network/docs/maintain-guides-async-backing">the Polkadot Wiki</a>.
 //! Furthermore, the parachain should have already been upgraded according to the guide.</div>
 //!
 //! ## Quick introduction to elastic scaling
@@ -70,9 +70,10 @@
 //! - Ensure enough coretime is assigned to the parachain. For maximum throughput the upper bound is
 //!   3 cores.
 //!
-//! <div class="warning">Phase 1 is not needed if using the `polkadot-parachain` binary built
-//! from the latest polkadot-sdk release! Simply pass the `--experimental-use-slot-based` parameter
-//! to the command line and jump to Phase 2.</div>
+//! <div class="warning">Phase 1 is not needed if using the <code>polkadot-parachain</code> binary
+//! built from the latest polkadot-sdk release! Simply pass the
+//! <code>--experimental-use-slot-based</code> parameter to the command line and jump to Phase
+//! 2.</div>
 //!
 //! The following steps assume using the cumulus parachain template.
 //!

docs/sdk/src/guides/enable_metadata_hash.rs

@@ -16,15 +16,15 @@
 //! the metadata for one or more networks. The next problem is that the offline wallet/user can not
 //! trust the metadata to be correct. It is very important for the metadata to be correct or
 //! otherwise an attacker could change them in a way that the offline wallet decodes a transaction
-//! in a different way than what it will be decoded to on chain. So, the user may signs an incorrect
-//! transaction leading to unexpecting behavior.
+//! in a different way than what it will be decoded to on chain. So, the user may sign an incorrect
+//! transaction leading to unexpected behavior.
 //!
 //! The metadata hash verification circumvents the issues of the huge metadata and the need to trust
 //! some metadata blob to be correct. To generate a hash for the metadata, the metadata is chunked,
 //! these chunks are put into a merkle tree and then the root of this merkle tree is the "metadata
 //! hash". For a more technical explanation on how it works, see
 //! [RFC78](https://polkadot-fellows.github.io/RFCs/approved/0078-merkleized-metadata.html). At compile
-//! time the metadata hash is generated and "backed" into the runtime. This makes it extremely cheap
+//! time the metadata hash is generated and "baked" into the runtime. This makes it extremely cheap
 //! for the runtime to verify on chain that the metadata hash is correct. By having the runtime
 //! verify the hash on chain, the user also doesn't need to trust the offchain metadata. If the
 //! metadata hash doesn't match the on chain metadata hash the transaction will be rejected. The

docs/sdk/src/guides/enable_pov_reclaim.rs

@@ -1,3 +1,5 @@
+//! # Enable storage weight reclaiming
+//!
 //! This guide will teach you how to enable storage weight reclaiming for a parachain. The
 //! explanations in this guide assume a project structure similar to the one detailed in
 //! the [substrate documentation](crate::polkadot_sdk::substrate#anatomy-of-a-binary-crate). Full

docs/sdk/src/guides/mod.rs

@@ -15,21 +15,21 @@
 /// Write your first simple pallet, learning the most most basic features of FRAME along the way.
 pub mod your_first_pallet;
 
-/// Writing your first real [runtime](`crate::reference_docs::wasm_meta_protocol`), and successfully
+/// Write your first real [runtime](`crate::reference_docs::wasm_meta_protocol`),
 /// compiling it to [WASM](crate::polkadot_sdk::substrate#wasm-build).
 pub mod your_first_runtime;
 
-/// Running the given runtime with a node. No specific consensus mechanism is used at this stage.
+// /// Running the given runtime with a node. No specific consensus mechanism is used at this stage.
 // TODO
 // pub mod your_first_node;
 
-/// How to enhance a given runtime and node to be cumulus-enabled, run it as a parachain and connect
-/// it to a relay-chain.
+// /// How to enhance a given runtime and node to be cumulus-enabled, run it as a parachain
+// /// and connect it to a relay-chain.
 // TODO
 // pub mod cumulus_enabled_parachain;
 
-/// How to make a given runtime XCM-enabled, capable of sending messages (`Transact`) between itself
-/// and the relay chain to which it is connected.
+// /// How to make a given runtime XCM-enabled, capable of sending messages (`Transact`) between
+// /// itself and the relay chain to which it is connected.
 // TODO
 // pub mod xcm_enabled_parachain;