Skip to content
  1. Jan 22, 2024
  3. Jan 20, 2024
  5. Jan 19, 2024
  7. Jan 18, 2024
  9. Jan 17, 2024
  11. Jan 16, 2024
    • Francisco Aguirre's avatar
      XCMv4 (#1230) · 8428f678
      Francisco Aguirre authored 
      

# Note for reviewer

Most changes are just syntax changes necessary for the new version.
Most important files should be the ones under the `xcm` folder.

# Description 

Added XCMv4.

## Removed `Multi` prefix
The following types have been renamed:
- MultiLocation -> Location
- MultiAsset -> Asset
- MultiAssets -> Assets
- InteriorMultiLocation -> InteriorLocation
- MultiAssetFilter -> AssetFilter
- VersionedMultiAsset -> VersionedAsset
- WildMultiAsset -> WildAsset
- VersionedMultiLocation -> VersionedLocation

In order to fix a name conflict, the `Assets` in `xcm-executor` were
renamed to `HoldingAssets`, as they represent assets in holding.

## Removed `Abstract` asset id

It was not being used anywhere and this simplifies the code.

Now assets are just constructed as follows:

```rust
let asset: Asset = (AssetId(Location::new(1, Here)), 100u128).into();
```

No need for specifying `Concrete` anymore.

## Outcome is now a named fields struct

Instead of

```rust
pub enum Outcome {
  Complete(Weight),
  Incomplete(Weight, Error),
  Error(Error),
}
```

we now have

```rust
pub enum Outcome {
  Complete { used: Weight },
  Incomplete { used: Weight, error: Error },
  Error { error: Error },
}
```

## Added Reanchorable trait

Now both locations and assets implement this trait, making it easier to
reanchor both.

## New syntax for building locations and junctions

Now junctions are built using the following methods:

```rust
let location = Location {
    parents: 1,
    interior: [Parachain(1000), PalletInstance(50), GeneralIndex(1984)].into()
};
```

or

```rust
let location = Location::new(1, [Parachain(1000), PalletInstance(50), GeneralIndex(1984)]);
```

And they are matched like so:

```rust
match location.unpack() {
  (1, [Parachain(id)]) => ...
  (0, Here) => ...,
  (1, [_]) => ...,
}
```

This syntax is mandatory in v4, and has been also implemented for v2 and
v3 for easier migration.

This was needed to make all sizes smaller.

# TODO
- [x] Scaffold v4
- [x] Port github.com/paritytech/polkadot/pull/7236
- [x] Remove `Multi` prefix
- [x] Remove `Abstract` asset id

---------

Co-authored-by: command-bot <>
Co-authored-by: default avatarKeith Yeung <[email protected]>
      8428f678
    • Xavier Lau's avatar
      CI check features (#1708) · 05cfb02b
      Xavier Lau authored 
      To resolve issue #1136.

This is a cross verification against zepter.

- [cargo-featalign](https://github.com/hack-ink/cargo-featalign):
Verifies the proper propagation of all features.
- [zepter](https://github.com/ggwpez/zepter): Checks for accidentally
enabled features.

cc @ggwpez

 

---
Switch to a new branch. Original PR #1537.

---------

Signed-off-by: default avatarXavier Lau <[email protected]>
Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
Co-authored-by: default avatarChevdor <[email protected]>
      05cfb02b
    • Bastian Köcher's avatar
      Some random fixes (#2936) · 1c2db174
      Bastian Köcher authored 
      - Do not disable `std` feature in the integration tests
- `contracts-fixtures` test should only check for `riscv` build when the
feature is enabled
      1c2db174
  13. Jan 15, 2024
  15. Jan 13, 2024
  17. Jan 12, 2024
  19. Jan 11, 2024
    • Michal Kucharczyk's avatar
      frame-support: sp-runtime dependency updated (serde) (#2907) · c8112e2c
      Michal Kucharczyk authored 
      `frame-support` crate compilation fails (reported by @koute):

```
$ cargo check --no-default-features --target=wasm32-unknown-unknown

error[E0277]: the trait bound `GC: Serialize` is not satisfied
    --> substrate/frame/support/src/genesis_builder_helper.rs:32:24
     |
32   |     serde_json::to_string(&GC::default())
     |     --------------------- ^^^^^^^^^^^^^^ the trait `Serialize` is not implemented for `GC`
     |     |
     |     required by a bound introduced by this call
     |
note: required by a bound in `serde_json::to_string`
    --> /home/kou/.cargo/registry/src/index.crates.io-6f17d22bba15001f/serde_json-1.0.111/src/ser.rs:2209:17
     |
2207 | pub fn to_string<T>(value: &T) -> Result<String>
     |        --------- required by a bound in this function
2208 | where
2209 |     T: ?Sized + Serialize,
     |                 ^^^^^^^^^ required by this bound in `to_string`
help: consider further restricting this bound
     |
30   |     GC: BuildGenesisConfig + Default + serde::Serialize,
     |                                      ++++++++++++++++++
```

This PR should fix this.

For all runtimes `sp-runtime/serde` feature was likely enabled by this
(and few other pallets):

https://github.com/paritytech/polkadot-sdk/blob/f2a750ee86e72c9ab677aaf588d0a33ee8446bef/substrate/frame/system/Cargo.toml#L27
      c8112e2c
  21. Jan 10, 2024
  23. Jan 09, 2024
  25. Jan 08, 2024
  27. Jan 07, 2024
  29. Jan 05, 2024
  31. Jan 04, 2024
    • PG Herveou's avatar
      Contracts build risc-v fixtures (#2554) · f82c2977
      PG Herveou authored 
      

Follow up from #2347 this time to verify that fixtures build to RISC-V

---------

Co-authored-by: default avataralvicsam <[email protected]>
Co-authored-by: default avatarAlexander Samusev <[email protected]>
Co-authored-by: default avatarAlexander Theißen <[email protected]>
      f82c2977
    • Lauro Gripa's avatar
      Fix vote weights of ranked members in the Society pallet (#2758) · 924089ff
      Lauro Gripa authored 
      

This PR fixes a bug in the tally accrual of approvals/rejections for
Candidates and Defender. The issue happened because:
- The `match maybe_old` is reducing `weight` from the tally:
```
Some(Vote { approve: true, weight }) => tally.approvals.saturating_reduce(weight),
Some(Vote { approve: false, weight }) => tally.rejections.saturating_reduce(weight),
```
- But `match approval` is accruing only `1` to the tally:
```
true => tally.approvals.saturating_accrue(1),
false => tally.rejections.saturating_accrue(1),
```

This way, if a member is rank 1 his vote is going to have weight 1 when
accruing but weight 4 when reducing from the tally. For example, let's
say:
- There's a Candidate with 0 approvals and 12 rejections;
- A ranked Member votes against the Candidate;
- The tally changes to 0 approvals and 13 rejections (should be 16);
- The Member changes his vote to an approval;
- Now tally changes to 1 approvals and 9 rejections, removing the
accrued approvals from other Members;
- If the Member keeps changing his vote, it wipes the tally clean.

So this PR changes `match approval` to accrue `weight` instead of just
`1` and changes the tests:
- Fixes `challenges_work`. This test started failing after the fix. The
reason is that the test assumes that all Members have equal weights to
their votes, but Member 10 is ranked, so his vote should have weight 4
against the Defender. So instead of using Member 10, I added Member 50
of rank 0 to keep the same logic;
- Improves `votes_are_working`. Added some assertions to check if the
tally is correct even after a ranked Member changes his vote a couple
times;
- Fixes `waive_repay_works`. Unrelated to the bug, but this test was
yielding a false positive. The test is ranking up Member 20, but
asserting the rank of Member 10, which is already ranked up.

---------

Co-authored-by: default avatarBastian Köcher <[email protected]>
Co-authored-by: command-bot <>
      924089ff