…allet pallet_balances --clean'

…allet pallet_balances'

…t pallet_balances'

…nto HEAD

…=westend --target_dir=polkadot --pallet=pallet_balances

…=westend --target_dir=polkadot --pallet=pallet_balances --machine=y

Co-authored-by: GitHub Action <[email protected]>
Co-authored-by: Cyrill Leutwiler <[email protected]>

[`LocalTransactionPool`
trait](https://github.com/paritytech/polkadot-sdk/blob/d5b96e9e7f24adc1799f8e426c5cb69b4f2dbf8a/substrate/client/transaction-pool/api/src/lib.rs#L408-L426)
is now implemented for `ForkAwareTransactionPool`.

Closes paritytech#5493

)

I noticed that hardware benchmarks are being run even though we pass the
--no-hardware-benchmarks cli flag. After some debugging, the cause is an
incorrect usage of the `then_some` method.

From [std
docs](https://doc.rust-lang.org/std/primitive.bool.html#method.then_some):

> Arguments passed to then_some are eagerly evaluated; if you are
passing the result of a function call, it is recommended to use
[then](https://doc.rust-lang.org/std/primitive.bool.html#method.then),
which is lazily evaluated.

```rust
let mut a = 0;
let mut function_with_side_effects = || { a += 1; };

true.then_some(function_with_side_effects());
false.then_some(function_with_side_effects());

// `a` is incremented twice because the value passed to `then_some` is
// evaluated eagerly.
assert_eq!(a, 2);
```

This PR fixes all the similar usages of the `then_some` method across
the codebase.

polkadot address: 138eUqXvUYT3o4GdbnWQfGRzM8yDWh5Q2eFrFULL7RAXzdWD

---------

Signed-off-by: Oliver Tale-Yazdi <[email protected]>
Co-authored-by: Shawn Tabrizi <[email protected]>
Co-authored-by: Oliver Tale-Yazdi <[email protected]>

…paritytech#6080)

A follow-up to paritytech#5599.
Assets in a pool with the native one are returned from
`query_acceptable_payment_assets`. Now those assets can be used in
`query_weight_to_asset_fee` to get the correct amount that needs to be
paid.

---------

Co-authored-by: command-bot <>

Add pallet-revive to Westend runtime, and configure the runtime to
accept Ethereum signed transaction

provides low-level documentation on how the omni-node is meant to work.
This is meant to act as reusable material for other teams (e.g.
Papermoon and W3F) to use and integrate into the high level Polkadot
documentation.

Broadly speaking, for omni-node to have great rust-docs, we need to
focus on the following crates, all of which got a bit of love in this
PR:

1. `sp-genesis-builder`
2. `polkadot-omni-node`
3. `polkadot-omni-node-lib`
4. `frame-omni-bencher`

On top of this, we have now: 

* `polkadot_sdk_docs::guides` contains two new steps demonstrating the
most basic version of composing your pallet, putting it into a runtime,
and putting that runtime into omni-node
* `polkadot_sdk_docs::reference_docs::omni_node` to explain in more
detail how omni-node differs from the old-school node.
* `polkadot_sdk_docs::reference_docs::frame_weight_benchmarking` to
finally have a minimal reference about weights and benchmarking.
* It provides tests for some of the steps in
paritytech#5568


closes paritytech#5568
closes paritytech#4781

Next steps

- [x] Ensure the README of the parachain template is up-to-date.
@iulianbarbu
- [ ] Readme for `polkadot-omni-node` and similar is updated. For now,
use `cargo-readme` and copy over the rust-docs.

To build the branch locally and run this:
https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/meta_contributing/index.html#how-to-develop-locally

---------

Co-authored-by: Iulian Barbu <[email protected]>
Co-authored-by: Sebastian Kunert <[email protected]>
Co-authored-by: Michal Kucharczyk <[email protected]>

Closes paritytech#6161

Westend BridgeHub freezes for a while at block 3 and if we try to init
the bridge and fund the accounts during that time, it fails. So we wait
untill all the parachains produced at least 10 blocks, in order to make
sure that they work reliably.

Fix hardcoded gas limits in tests

---------

Co-authored-by: GitHub Action <[email protected]>

…hains (paritytech#6212)

Added missing API methods to Rococo and Westend parachains.
Preparatory work for making chopstick tests run smoothly.
Follow-up of
[PR#6039](paritytech#6039)

…ritytech#6216)

# Description

Snowbridge PNA has been audited. A number of issues where raised due to
not understanding the fee model for Polkadot Native Assets(PNA)
implementation. This PR addresses this by adding more comments and
better naming of private functions.

## Integration

None, documentation and private method name changes.

The approval-voting-parallel introduced with
paritytech#4849 has been tested on
`versi` and approximately 3 weeks on parity's existing kusama nodes
paritytech/devops#3583, things worked as
expected, so enable it by default on all kusama nodes in the next
release.

The next step will be enabling by default on polkadot if no issue
arrises while running on kusama.

---------

Signed-off-by: Alexandru Gheorghe <[email protected]>

Fix paritytech#5185

also implement handling of attr in expansion in construct-runtime

---------

Co-authored-by: Oliver Tale-Yazdi <[email protected]>
Co-authored-by: Bastian Köcher <[email protected]>

Flaky tests reported in

paritytech#6062
paritytech#6063 (already fixed)

Thx!

Just fix a tiny typo

The max size of a message should not depend on the weight left in a
given execution context. Instead the max message size depends on the
service weights configured for the pallet. A message that may does not
fit into `on_idle` is not automatically overweight, because it may can
be executed successfully in `on_initialize` or in another block in
`on_idle` when there is more weight left.

---------

Co-authored-by: GitHub Action <[email protected]>

Co-authored-by: GitHub Action <[email protected]>
Co-authored-by: Cyrill Leutwiler <[email protected]>

[`LocalTransactionPool`
trait](https://github.com/paritytech/polkadot-sdk/blob/d5b96e9e7f24adc1799f8e426c5cb69b4f2dbf8a/substrate/client/transaction-pool/api/src/lib.rs#L408-L426)
is now implemented for `ForkAwareTransactionPool`.

Closes paritytech#5493

)

I noticed that hardware benchmarks are being run even though we pass the
--no-hardware-benchmarks cli flag. After some debugging, the cause is an
incorrect usage of the `then_some` method.

From [std
docs](https://doc.rust-lang.org/std/primitive.bool.html#method.then_some):

> Arguments passed to then_some are eagerly evaluated; if you are
passing the result of a function call, it is recommended to use
[then](https://doc.rust-lang.org/std/primitive.bool.html#method.then),
which is lazily evaluated.

```rust
let mut a = 0;
let mut function_with_side_effects = || { a += 1; };

true.then_some(function_with_side_effects());
false.then_some(function_with_side_effects());

// `a` is incremented twice because the value passed to `then_some` is
// evaluated eagerly.
assert_eq!(a, 2);
```

This PR fixes all the similar usages of the `then_some` method across
the codebase.

polkadot address: 138eUqXvUYT3o4GdbnWQfGRzM8yDWh5Q2eFrFULL7RAXzdWD

---------

Signed-off-by: Oliver Tale-Yazdi <[email protected]>
Co-authored-by: Shawn Tabrizi <[email protected]>
Co-authored-by: Oliver Tale-Yazdi <[email protected]>

…paritytech#6080)

A follow-up to paritytech#5599.
Assets in a pool with the native one are returned from
`query_acceptable_payment_assets`. Now those assets can be used in
`query_weight_to_asset_fee` to get the correct amount that needs to be
paid.

---------

Co-authored-by: command-bot <>

Add pallet-revive to Westend runtime, and configure the runtime to
accept Ethereum signed transaction

provides low-level documentation on how the omni-node is meant to work.
This is meant to act as reusable material for other teams (e.g.
Papermoon and W3F) to use and integrate into the high level Polkadot
documentation.

Broadly speaking, for omni-node to have great rust-docs, we need to
focus on the following crates, all of which got a bit of love in this
PR:

1. `sp-genesis-builder`
2. `polkadot-omni-node`
3. `polkadot-omni-node-lib`
4. `frame-omni-bencher`

On top of this, we have now: 

* `polkadot_sdk_docs::guides` contains two new steps demonstrating the
most basic version of composing your pallet, putting it into a runtime,
and putting that runtime into omni-node
* `polkadot_sdk_docs::reference_docs::omni_node` to explain in more
detail how omni-node differs from the old-school node.
* `polkadot_sdk_docs::reference_docs::frame_weight_benchmarking` to
finally have a minimal reference about weights and benchmarking.
* It provides tests for some of the steps in
paritytech#5568


closes paritytech#5568
closes paritytech#4781

Next steps

- [x] Ensure the README of the parachain template is up-to-date.
@iulianbarbu
- [ ] Readme for `polkadot-omni-node` and similar is updated. For now,
use `cargo-readme` and copy over the rust-docs.

To build the branch locally and run this:
https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/meta_contributing/index.html#how-to-develop-locally

---------

Co-authored-by: Iulian Barbu <[email protected]>
Co-authored-by: Sebastian Kunert <[email protected]>
Co-authored-by: Michal Kucharczyk <[email protected]>

Closes paritytech#6161

Westend BridgeHub freezes for a while at block 3 and if we try to init
the bridge and fund the accounts during that time, it fails. So we wait
untill all the parachains produced at least 10 blocks, in order to make
sure that they work reliably.

Fix hardcoded gas limits in tests

---------

Co-authored-by: GitHub Action <[email protected]>

…hains (paritytech#6212)

Added missing API methods to Rococo and Westend parachains.
Preparatory work for making chopstick tests run smoothly.
Follow-up of
[PR#6039](paritytech#6039)

…ritytech#6216)

# Description

Snowbridge PNA has been audited. A number of issues where raised due to
not understanding the fee model for Polkadot Native Assets(PNA)
implementation. This PR addresses this by adding more comments and
better naming of private functions.

## Integration

None, documentation and private method name changes.

The approval-voting-parallel introduced with
paritytech#4849 has been tested on
`versi` and approximately 3 weeks on parity's existing kusama nodes
paritytech/devops#3583, things worked as
expected, so enable it by default on all kusama nodes in the next
release.

The next step will be enabling by default on polkadot if no issue
arrises while running on kusama.

---------

Signed-off-by: Alexandru Gheorghe <[email protected]>

Fix paritytech#5185

also implement handling of attr in expansion in construct-runtime

---------

Co-authored-by: Oliver Tale-Yazdi <[email protected]>
Co-authored-by: Bastian Köcher <[email protected]>

Flaky tests reported in

paritytech#6062
paritytech#6063 (already fixed)

Thx!

Just fix a tiny typo

The max size of a message should not depend on the weight left in a
given execution context. Instead the max message size depends on the
service weights configured for the pallet. A message that may does not
fit into `on_idle` is not automatically overweight, because it may can
be executed successfully in `on_initialize` or in another block in
`on_idle` when there is more weight left.

---------

Co-authored-by: GitHub Action <[email protected]>

Co-authored-by: GitHub Action <[email protected]>
Co-authored-by: Cyrill Leutwiler <[email protected]>

[`LocalTransactionPool`
trait](https://github.com/paritytech/polkadot-sdk/blob/d5b96e9e7f24adc1799f8e426c5cb69b4f2dbf8a/substrate/client/transaction-pool/api/src/lib.rs#L408-L426)
is now implemented for `ForkAwareTransactionPool`.

Closes paritytech#5493

)

I noticed that hardware benchmarks are being run even though we pass the
--no-hardware-benchmarks cli flag. After some debugging, the cause is an
incorrect usage of the `then_some` method.

From [std
docs](https://doc.rust-lang.org/std/primitive.bool.html#method.then_some):

> Arguments passed to then_some are eagerly evaluated; if you are
passing the result of a function call, it is recommended to use
[then](https://doc.rust-lang.org/std/primitive.bool.html#method.then),
which is lazily evaluated.

```rust
let mut a = 0;
let mut function_with_side_effects = || { a += 1; };

true.then_some(function_with_side_effects());
false.then_some(function_with_side_effects());

// `a` is incremented twice because the value passed to `then_some` is
// evaluated eagerly.
assert_eq!(a, 2);
```

This PR fixes all the similar usages of the `then_some` method across
the codebase.

polkadot address: 138eUqXvUYT3o4GdbnWQfGRzM8yDWh5Q2eFrFULL7RAXzdWD

---------

Signed-off-by: Oliver Tale-Yazdi <[email protected]>
Co-authored-by: Shawn Tabrizi <[email protected]>
Co-authored-by: Oliver Tale-Yazdi <[email protected]>

…paritytech#6080)

A follow-up to paritytech#5599.
Assets in a pool with the native one are returned from
`query_acceptable_payment_assets`. Now those assets can be used in
`query_weight_to_asset_fee` to get the correct amount that needs to be
paid.

---------

Co-authored-by: command-bot <>

Add pallet-revive to Westend runtime, and configure the runtime to
accept Ethereum signed transaction

provides low-level documentation on how the omni-node is meant to work.
This is meant to act as reusable material for other teams (e.g.
Papermoon and W3F) to use and integrate into the high level Polkadot
documentation.

Broadly speaking, for omni-node to have great rust-docs, we need to
focus on the following crates, all of which got a bit of love in this
PR:

1. `sp-genesis-builder`
2. `polkadot-omni-node`
3. `polkadot-omni-node-lib`
4. `frame-omni-bencher`

On top of this, we have now: 

* `polkadot_sdk_docs::guides` contains two new steps demonstrating the
most basic version of composing your pallet, putting it into a runtime,
and putting that runtime into omni-node
* `polkadot_sdk_docs::reference_docs::omni_node` to explain in more
detail how omni-node differs from the old-school node.
* `polkadot_sdk_docs::reference_docs::frame_weight_benchmarking` to
finally have a minimal reference about weights and benchmarking.
* It provides tests for some of the steps in
paritytech#5568


closes paritytech#5568
closes paritytech#4781

Next steps

- [x] Ensure the README of the parachain template is up-to-date.
@iulianbarbu
- [ ] Readme for `polkadot-omni-node` and similar is updated. For now,
use `cargo-readme` and copy over the rust-docs.

To build the branch locally and run this:
https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/meta_contributing/index.html#how-to-develop-locally

---------

Co-authored-by: Iulian Barbu <[email protected]>
Co-authored-by: Sebastian Kunert <[email protected]>
Co-authored-by: Michal Kucharczyk <[email protected]>

Closes paritytech#6161

Westend BridgeHub freezes for a while at block 3 and if we try to init
the bridge and fund the accounts during that time, it fails. So we wait
untill all the parachains produced at least 10 blocks, in order to make
sure that they work reliably.

Fix hardcoded gas limits in tests

---------

Co-authored-by: GitHub Action <[email protected]>

…hains (paritytech#6212)

Added missing API methods to Rococo and Westend parachains.
Preparatory work for making chopstick tests run smoothly.
Follow-up of
[PR#6039](paritytech#6039)

…ritytech#6216)

# Description

Snowbridge PNA has been audited. A number of issues where raised due to
not understanding the fee model for Polkadot Native Assets(PNA)
implementation. This PR addresses this by adding more comments and
better naming of private functions.

## Integration

None, documentation and private method name changes.

The approval-voting-parallel introduced with
paritytech#4849 has been tested on
`versi` and approximately 3 weeks on parity's existing kusama nodes
paritytech/devops#3583, things worked as
expected, so enable it by default on all kusama nodes in the next
release.

The next step will be enabling by default on polkadot if no issue
arrises while running on kusama.

---------

Signed-off-by: Alexandru Gheorghe <[email protected]>

Fix paritytech#5185

also implement handling of attr in expansion in construct-runtime

---------

Co-authored-by: Oliver Tale-Yazdi <[email protected]>
Co-authored-by: Bastian Köcher <[email protected]>

Flaky tests reported in

paritytech#6062
paritytech#6063 (already fixed)

Thx!

Just fix a tiny typo

The max size of a message should not depend on the weight left in a
given execution context. Instead the max message size depends on the
service weights configured for the pallet. A message that may does not
fit into `on_idle` is not automatically overweight, because it may can
be executed successfully in `on_initialize` or in another block in
`on_idle` when there is more weight left.

---------

Co-authored-by: GitHub Action <[email protected]>

…t pallet_balances --clean'