Skip to content
  1. Apr 02, 2024
  2. Mar 27, 2024
  3. Mar 26, 2024
    • Dcompoze's avatar
      Fix spelling mistakes across the whole repository (#3808) · 002d9260
      Dcompoze authored
      **Update:** Pushed additional changes based on the review comments.
      
      **This pull request fixes various spelling mistakes in this
      repository.**
      
      Most of the changes are contained in the first **3** commits:
      
      - `Fix spelling mistakes in comments and docs`
      
      - `Fix spelling mistakes in test names`
      
      - `Fix spelling mistakes in error messages, panic messages, logs and
      tracing`
      
      Other source code spelling mistakes are separated into individual
      commits for easier reviewing:
      
      - `Fix the spelling of 'authority'`
      
      - `Fix the spelling of 'REASONABLE_HEADERS_IN_JUSTIFICATION_ANCESTRY'`
      
      - `Fix the spelling of 'prev_enqueud_messages'`
      
      - `Fix the spelling of 'endpoint'`
      
      - `Fix the spelling of 'children'`
      
      - `Fix the spelling of 'PenpalSiblingSovereignAccount'`
      
      - `Fix the spelling of 'PenpalSudoAccount'`
      
      - `Fix the spelling of 'insufficient'`
      
      - `Fix the spelling of 'PalletXcmExtrinsicsBenchmark'`
      
      - `Fix the spelling of 'subtracted'`
      
      - `Fix the spelling of 'CandidatePendingAvailability'`
      
      - `Fix the spelling of 'exclusive'`
      
      - `Fix the spelling of 'until'`
      
      - `Fix the spelling of 'discriminator'`
      
      - `Fix the spelling of 'nonexistent'`
      
      - `Fix the spelling of 'subsystem'`
      
      - `Fix the spelling of 'indices'`
      
      - `Fix the spelling of 'committed'`
      
      - `Fix the spelling of 'topology'`
      
      - `Fix the spelling of 'response'`
      
      - `Fix the spelling of 'beneficiary'`
      
      - `Fix the spelling of 'formatted'`
      
      - `Fix the spelling of 'UNKNOWN_PROOF_REQUEST'`
      
      - `Fix the spelling of 'succeeded'`
      
      - `Fix the spelling of 'reopened'`
      
      - `Fix the spelling of 'proposer'`
      
      - `Fix the spelling of 'InstantiationNonce'`
      
      - `Fix the spelling of 'depositor'`
      
      - `Fix the spelling of 'expiration'`
      
      - `Fix the spelling of 'phantom'`
      
      - `Fix the spelling of 'AggregatedKeyValue'`
      
      - `Fix the spelling of 'randomness'`
      
      - `Fix the spelling of 'defendant'`
      
      - `Fix the spelling of 'AquaticMammal'`
      
      - `Fix the spelling of 'transactions'`
      
      - `Fix the spelling of 'PassingTracingSubscriber'`
      
      - `Fix the spelling of 'TxSignaturePayload'`
      
      - `Fix the spelling of 'versioning'`
      
      - `Fix the spelling of 'descendant'`
      
      - `Fix the spelling of 'overridden'`
      
      - `Fix the spelling of 'network'`
      
      Let me know if this structure is adequate.
      
      **Note:** The usage of the words `Merkle`, `Merkelize`, `Merklization`,
      `Merkelization`, `Merkleization`, is somewhat inconsistent but I left it
      as it is.
      
      ~~**Note:** In some places the term `Receival` is used to refer to
      message reception, IMO `Reception` is the correct word here, but I left
      it as it is.~~
      
      ~~**Note:** In some places the term `Overlayed` is used instead of the
      more acceptable version `Overlaid` but I also left it as it is.~~
      
      ~~**Note:** In some places the term `Applyable` is used instead of the
      correct version `Applicable` but I also left it as it is.~~
      
      **Note:** Some usage of British vs American english e.g. `judgement` vs
      `judgment`, `initialise` vs `initialize`, `optimise` vs `optimize` etc.
      are both present in different places, but I suppose that's
      understandable given the number of contributors.
      
      ~~**Note:** There is a spelling mistake in `.github/CODEOWNERS` but it
      triggers errors in CI when I make changes to it, so I left it as it
      is.~~
      002d9260
  4. Mar 19, 2024
    • Juan Ignacio Rios's avatar
      Add HRMP notification handlers to the xcm-executor (#3696) · 8b3bf39a
      Juan Ignacio Rios authored
      
      
      Currently the xcm-executor returns an `Unimplemented` error if it
      receives any HRMP-related instruction.
      What I propose here, which is what we are currently doing in our forked
      executor at polimec, is to introduce a trait implemented by the executor
      which will handle those instructions.
      
      This way, if parachains want to keep the default behavior, they just use
      `()` and it will return unimplemented, but they can also implement their
      own logic to establish HRMP channels with other chains in an automated
      fashion, without requiring to go through governance.
      
      Our implementation is mentioned in the [polkadot HRMP
      docs](https://arc.net/l/quote/hduiivbu), and it was suggested to us to
      submit a PR to add these changes to polkadot-sdk.
      
      ---------
      
      Co-authored-by: default avatarBranislav Kontur <[email protected]>
      Co-authored-by: command-bot <>
      8b3bf39a
  5. Mar 15, 2024
  6. Mar 13, 2024
    • georgepisaltu's avatar
      Revert "FRAME: Create `TransactionExtension` as a replacement for... · bbd51ce8
      georgepisaltu authored
      
      Revert "FRAME: Create `TransactionExtension` as a replacement for `SignedExtension` (#2280)" (#3665)
      
      This PR reverts #2280 which introduced `TransactionExtension` to replace
      `SignedExtension`.
      
      As a result of the discussion
      [here](https://github.com/paritytech/polkadot-sdk/pull/3623#issuecomment-1986789700),
      the changes will be reverted for now with plans to reintroduce the
      concept in the future.
      
      ---------
      
      Signed-off-by: default avatargeorgepisaltu <[email protected]>
      bbd51ce8
  7. Mar 04, 2024
    • Gavin Wood's avatar
      FRAME: Create `TransactionExtension` as a replacement for `SignedExtension` (#2280) · fd5f9292
      Gavin Wood authored
      
      
      Closes #2160
      
      First part of [Extrinsic
      Horizon](https://github.com/paritytech/polkadot-sdk/issues/2415)
      
      Introduces a new trait `TransactionExtension` to replace
      `SignedExtension`. Introduce the idea of transactions which obey the
      runtime's extensions and have according Extension data (né Extra data)
      yet do not have hard-coded signatures.
      
      Deprecate the terminology of "Unsigned" when used for
      transactions/extrinsics owing to there now being "proper" unsigned
      transactions which obey the extension framework and "old-style" unsigned
      which do not. Instead we have __*General*__ for the former and
      __*Bare*__ for the latter. (Ultimately, the latter will be phased out as
      a type of transaction, and Bare will only be used for Inherents.)
      
      Types of extrinsic are now therefore:
      - Bare (no hardcoded signature, no Extra data; used to be known as
      "Unsigned")
      - Bare transactions (deprecated): Gossiped, validated with
      `ValidateUnsigned` (deprecated) and the `_bare_compat` bits of
      `TransactionExtension` (deprecated).
        - Inherents: Not gossiped, validated with `ProvideInherent`.
      - Extended (Extra data): Gossiped, validated via `TransactionExtension`.
        - Signed transactions (with a hardcoded signature).
        - General transactions (without a hardcoded signature).
      
      `TransactionExtension` differs from `SignedExtension` because:
      - A signature on the underlying transaction may validly not be present.
      - It may alter the origin during validation.
      - `pre_dispatch` is renamed to `prepare` and need not contain the checks
      present in `validate`.
      - `validate` and `prepare` is passed an `Origin` rather than a
      `AccountId`.
      - `validate` may pass arbitrary information into `prepare` via a new
      user-specifiable type `Val`.
      - `AdditionalSigned`/`additional_signed` is renamed to
      `Implicit`/`implicit`. It is encoded *for the entire transaction* and
      passed in to each extension as a new argument to `validate`. This
      facilitates the ability of extensions to acts as underlying crypto.
      
      There is a new `DispatchTransaction` trait which contains only default
      function impls and is impl'ed for any `TransactionExtension` impler. It
      provides several utility functions which reduce some of the tedium from
      using `TransactionExtension` (indeed, none of its regular functions
      should now need to be called directly).
      
      Three transaction version discriminator ("versions") are now
      permissible:
      - 0b000000100: Bare (used to be called "Unsigned"): contains Signature
      or Extra (extension data). After bare transactions are no longer
      supported, this will strictly identify an Inherents only.
      - 0b100000100: Old-school "Signed" Transaction: contains Signature and
      Extra (extension data).
      - 0b010000100: New-school "General" Transaction: contains Extra
      (extension data), but no Signature.
      
      For the New-school General Transaction, it becomes trivial for authors
      to publish extensions to the mechanism for authorizing an Origin, e.g.
      through new kinds of key-signing schemes, ZK proofs, pallet state,
      mutations over pre-authenticated origins or any combination of the
      above.
      
      ## Code Migration
      
      ### NOW: Getting it to build
      
      Wrap your `SignedExtension`s in `AsTransactionExtension`. This should be
      accompanied by renaming your aggregate type in line with the new
      terminology. E.g. Before:
      
      ```rust
      /// The SignedExtension to the basic transaction logic.
      pub type SignedExtra = (
      	/* snip */
      	MySpecialSignedExtension,
      );
      /// Unchecked extrinsic type as expected by this runtime.
      pub type UncheckedExtrinsic =
      	generic::UncheckedExtrinsic<Address, RuntimeCall, Signature, SignedExtra>;
      ```
      
      After:
      
      ```rust
      /// The extension to the basic transaction logic.
      pub type TxExtension = (
      	/* snip */
      	AsTransactionExtension<MySpecialSignedExtension>,
      );
      /// Unchecked extrinsic type as expected by this runtime.
      pub type UncheckedExtrinsic =
      	generic::UncheckedExtrinsic<Address, RuntimeCall, Signature, TxExtension>;
      ```
      
      You'll also need to alter any transaction building logic to add a
      `.into()` to make the conversion happen. E.g. Before:
      
      ```rust
      fn construct_extrinsic(
      		/* snip */
      ) -> UncheckedExtrinsic {
      	let extra: SignedExtra = (
      		/* snip */
      		MySpecialSignedExtension::new(/* snip */),
      	);
      	let payload = SignedPayload::new(call.clone(), extra.clone()).unwrap();
      	let signature = payload.using_encoded(|e| sender.sign(e));
      	UncheckedExtrinsic::new_signed(
      		/* snip */
      		Signature::Sr25519(signature),
      		extra,
      	)
      }
      ```
      
      After:
      
      ```rust
      fn construct_extrinsic(
      		/* snip */
      ) -> UncheckedExtrinsic {
      	let tx_ext: TxExtension = (
      		/* snip */
      		MySpecialSignedExtension::new(/* snip */).into(),
      	);
      	let payload = SignedPayload::new(call.clone(), tx_ext.clone()).unwrap();
      	let signature = payload.using_encoded(|e| sender.sign(e));
      	UncheckedExtrinsic::new_signed(
      		/* snip */
      		Signature::Sr25519(signature),
      		tx_ext,
      	)
      }
      ```
      
      ### SOON: Migrating to `TransactionExtension`
      
      Most `SignedExtension`s can be trivially converted to become a
      `TransactionExtension`. There are a few things to know.
      
      - Instead of a single trait like `SignedExtension`, you should now
      implement two traits individually: `TransactionExtensionBase` and
      `TransactionExtension`.
      - Weights are now a thing and must be provided via the new function `fn
      weight`.
      
      #### `TransactionExtensionBase`
      
      This trait takes care of anything which is not dependent on types
      specific to your runtime, most notably `Call`.
      
      - `AdditionalSigned`/`additional_signed` is renamed to
      `Implicit`/`implicit`.
      - Weight must be returned by implementing the `weight` function. If your
      extension is associated with a pallet, you'll probably want to do this
      via the pallet's existing benchmarking infrastructure.
      
      #### `TransactionExtension`
      
      Generally:
      - `pre_dispatch` is now `prepare` and you *should not reexecute the
      `validate` functionality in there*!
      - You don't get an account ID any more; you get an origin instead. If
      you need to presume an account ID, then you can use the trait function
      `AsSystemOriginSigner::as_system_origin_signer`.
      - You get an additional ticket, similar to `Pre`, called `Val`. This
      defines data which is passed from `validate` into `prepare`. This is
      important since you should not be duplicating logic from `validate` to
      `prepare`, you need a way of passing your working from the former into
      the latter. This is it.
      - This trait takes two type parameters: `Call` and `Context`. `Call` is
      the runtime call type which used to be an associated type; you can just
      move it to become a type parameter for your trait impl. `Context` is not
      currently used and you can safely implement over it as an unbounded
      type.
      - There's no `AccountId` associated type any more. Just remove it.
      
      Regarding `validate`:
      - You get three new parameters in `validate`; all can be ignored when
      migrating from `SignedExtension`.
      - `validate` returns a tuple on success; the second item in the tuple is
      the new ticket type `Self::Val` which gets passed in to `prepare`. If
      you use any information extracted during `validate` (off-chain and
      on-chain, non-mutating) in `prepare` (on-chain, mutating) then you can
      pass it through with this. For the tuple's last item, just return the
      `origin` argument.
      
      Regarding `prepare`:
      - This is renamed from `pre_dispatch`, but there is one change:
      - FUNCTIONALITY TO VALIDATE THE TRANSACTION NEED NOT BE DUPLICATED FROM
      `validate`!!
      - (This is different to `SignedExtension` which was required to run the
      same checks in `pre_dispatch` as in `validate`.)
      
      Regarding `post_dispatch`:
      - Since there are no unsigned transactions handled by
      `TransactionExtension`, `Pre` is always defined, so the first parameter
      is `Self::Pre` rather than `Option<Self::Pre>`.
      
      If you make use of `SignedExtension::validate_unsigned` or
      `SignedExtension::pre_dispatch_unsigned`, then:
      - Just use the regular versions of these functions instead.
      - Have your logic execute in the case that the `origin` is `None`.
      - Ensure your transaction creation logic creates a General Transaction
      rather than a Bare Transaction; this means having to include all
      `TransactionExtension`s' data.
      - `ValidateUnsigned` can still be used (for now) if you need to be able
      to construct transactions which contain none of the extension data,
      however these will be phased out in stage 2 of the Transactions Horizon,
      so you should consider moving to an extension-centric design.
      
      ## TODO
      
      - [x] Introduce `CheckSignature` impl of `TransactionExtension` to
      ensure it's possible to have crypto be done wholly in a
      `TransactionExtension`.
      - [x] Deprecate `SignedExtension` and move all uses in codebase to
      `TransactionExtension`.
        - [x] `ChargeTransactionPayment`
        - [x] `DummyExtension`
        - [x] `ChargeAssetTxPayment` (asset-tx-payment)
        - [x] `ChargeAssetTxPayment` (asset-conversion-tx-payment)
        - [x] `CheckWeight`
        - [x] `CheckTxVersion`
        - [x] `CheckSpecVersion`
        - [x] `CheckNonce`
        - [x] `CheckNonZeroSender`
        - [x] `CheckMortality`
        - [x] `CheckGenesis`
        - [x] `CheckOnlySudoAccount`
        - [x] `WatchDummy`
        - [x] `PrevalidateAttests`
        - [x] `GenericSignedExtension`
        - [x] `SignedExtension` (chain-polkadot-bulletin)
        - [x] `RefundSignedExtensionAdapter`
      - [x] Implement `fn weight` across the board.
      - [ ] Go through all pre-existing extensions which assume an account
      signer and explicitly handle the possibility of another kind of origin.
      - [x] `CheckNonce` should probably succeed in the case of a non-account
      origin.
      - [x] `CheckNonZeroSender` should succeed in the case of a non-account
      origin.
      - [x] `ChargeTransactionPayment` and family should fail in the case of a
      non-account origin.
        - [ ] 
      - [x] Fix any broken tests.
      
      ---------
      
      Signed-off-by: default avatargeorgepisaltu <[email protected]>
      Signed-off-by: default avatarAlexandru Vasile <[email protected]>
      Signed-off-by: default avatardependabot[bot] <[email protected]>
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      Signed-off-by: default avatarAlexandru Gheorghe <[email protected]>
      Signed-off-by: default avatarAndrei Sandu <[email protected]>
      Co-authored-by: default avatarNikhil Gupta <[email protected]>
      Co-authored-by: default avatargeorgepisaltu <[email protected]>
      Co-authored-by: default avatarChevdor <[email protected]>
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      Co-authored-by: default avatarMaciej <[email protected]>
      Co-authored-by: default avatarJavier Viola <[email protected]>
      Co-authored-by: default avatarMarcin S. <[email protected]>
      Co-authored-by: default avatarTsvetomir Dimitrov <[email protected]>
      Co-authored-by: default avatarJavier Bullrich <[email protected]>
      Co-authored-by: default avatarKoute <[email protected]>
      Co-authored-by: default avatarAdrian Catangiu <[email protected]>
      Co-authored-by: Vladimir Istyufeev's avatarVladimir Istyufeev <[email protected]>
      Co-authored-by: default avatarRoss Bulat <[email protected]>
      Co-authored-by: default avatarGonçalo Pestana <[email protected]>
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      Co-authored-by: default avatarSvyatoslav Nikolsky <[email protected]>
      Co-authored-by: default avatarAndré Silva <[email protected]>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatars0me0ne-unkn0wn <[email protected]>
      Co-authored-by: default avatarordian <[email protected]>
      Co-authored-by: default avatarSebastian Kunert <[email protected]>
      Co-authored-by: default avatarAaro Altonen <[email protected]>
      Co-authored-by: default avatarDmitry Markin <[email protected]>
      Co-authored-by: default avatarAlexandru Vasile <[email protected]>
      Co-authored-by: default avatarAlexander Samusev <[email protected]>
      Co-authored-by: default avatarJulian Eager <[email protected]>
      Co-authored-by: default avatarMichal Kucharczyk <[email protected]>
      Co-authored-by: default avatarDavide Galassi <[email protected]>
      Co-authored-by: default avatarDónal Murray <[email protected]>
      Co-authored-by: default avataryjh <[email protected]>
      Co-authored-by: default avatarTom Mi <[email protected]>
      Co-authored-by: default avatardependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
      Co-authored-by: default avatarWill | Paradox | ParaNodes.io <[email protected]>
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      Co-authored-by: default avatarJoshy Orndorff <[email protected]>
      Co-authored-by: default avatarJoshy Orndorff <[email protected]>
      Co-authored-by: default avatarPG Herveou <[email protected]>
      Co-authored-by: default avatarAlexander Theißen <[email protected]>
      Co-authored-by: default avatarKian Paimani <[email protected]>
      Co-authored-by: default avatarJuan Girini <[email protected]>
      Co-authored-by: default avatarbader y <[email protected]>
      Co-authored-by: default avatarJames Wilson <[email protected]>
      Co-authored-by: default avatarjoe petrowski <[email protected]>
      Co-authored-by: default avatarasynchronous rob <[email protected]>
      Co-authored-by: default avatarParth <[email protected]>
      Co-authored-by: default avatarAndrew Jones <[email protected]>
      Co-authored-by: default avatarJonathan Udd <[email protected]>
      Co-authored-by: default avatarSerban Iorga <[email protected]>
      Co-authored-by: default avatarEgor_P <[email protected]>
      Co-authored-by: default avatarBranislav Kontur <[email protected]>
      Co-authored-by: default avatarEvgeny Snitko <[email protected]>
      Co-authored-by: default avatarJust van Stam <[email protected]>
      Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
      Co-authored-by: default avatargupnik <[email protected]>
      Co-authored-by: default avatardzmitry-lahoda <[email protected]>
      Co-authored-by: default avatarzhiqiangxu <[email protected]>
      Co-authored-by: default avatarNazar Mokrynskyi <[email protected]>
      Co-authored-by: default avatarAnwesh <[email protected]>
      Co-authored-by: default avatarcheme <[email protected]>
      Co-authored-by: default avatarSam Johnson <[email protected]>
      Co-authored-by: default avatarkianenigma <[email protected]>
      Co-authored-by: default avatarJegor Sidorenko <[email protected]>
      Co-authored-by: default avatarMuharem <[email protected]>
      Co-authored-by: default avatarjoepetrowski <[email protected]>
      Co-authored-by: default avatarAlexandru Gheorghe <[email protected]>
      Co-authored-by: default avatarGabriel Facco de Arruda <[email protected]>
      Co-authored-by: default avatarSquirrel <[email protected]>
      Co-authored-by: default avatarAndrei Sandu <[email protected]>
      Co-authored-by: default avatargeorgepisaltu <[email protected]>
      Co-authored-by: command-bot <>
      fd5f9292
  8. Feb 13, 2024
  9. Feb 12, 2024
    • Oliver Tale-Yazdi's avatar
      Lift dependencies to the workspace (Part 1) (#2070) · e80c2473
      Oliver Tale-Yazdi authored
      Changes (partial https://github.com/paritytech/polkadot-sdk/issues/994):
      - Set log to `0.4.20` everywhere
      - Lift `log` to the workspace
      
      Starting with a simpler one after seeing
      https://github.com/paritytech/polkadot-sdk/pull/2065 from @jsdw
      
      .
      This sets the `default-features` to `false` in the root and then
      overwrites that in each create to its original value. This is necessary
      since otherwise the `default` features are additive and its impossible
      to disable them in the crate again once they are enabled in the
      workspace.
      
      I am using a tool to do this, so its mostly a test to see that it works
      as expected.
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      e80c2473
  10. Feb 08, 2024
    • Louis Merlin's avatar
      Add try_state and integrity_test to XCM simulator fuzzer (#3222) · 84d89e37
      Louis Merlin authored
      This adds `try_state()` and `integrity_test()` to the four runtimes of
      the XCM-simulator fuzzer.
      
      With this, we are able to stress-test [message-queue's
      try_state](https://github.com/paritytech/polkadot-sdk/blob/7df1ae3b/substrate/frame/message-queue/src/lib.rs#L1245-L1347).
      
      This also adds the `Transact` block-listing from #2424 to avoid
      false-positives.
      
      Thank you @ggwpez for the help with the runtime configurations.
      84d89e37
  11. Jan 31, 2024
    • Branislav Kontur's avatar
      [frame] `#[pallet::composite_enum]` improved variant count handling + removed... · bb8ddc46
      Branislav Kontur authored
      [frame] `#[pallet::composite_enum]` improved variant count handling + removed `pallet_balances`'s `MaxHolds` config (#2657)
      
      I started this investigation/issue based on @liamaharon
      
       question
      [here](https://github.com/paritytech/polkadot-sdk/pull/1801#discussion_r1410452499).
      
      ## Problem
      
      The `pallet_balances` integrity test should correctly detect that the
      runtime has correct distinct `HoldReasons` variant count. I assume the
      same situation exists for RuntimeFreezeReason.
      
      It is not a critical problem, if we set `MaxHolds` with a sufficiently
      large value, everything should be ok. However, in this case, the
      integrity_test check becomes less useful.
      
      **Situation for "any" runtime:**
      - `HoldReason` enums from different pallets:
      ```rust
              /// from pallet_nis
              #[pallet::composite_enum]
      	pub enum HoldReason {
      		NftReceipt,
      	}
      
              /// from pallet_preimage
              #[pallet::composite_enum]
      	pub enum HoldReason {
      		Preimage,
      	}
      
              // from pallet_state-trie-migration
              #[pallet::composite_enum]
      	pub enum HoldReason {
      		SlashForContinueMigrate,
      		SlashForMigrateCustomTop,
      		SlashForMigrateCustomChild,
      	}
      ```
      
      - generated `RuntimeHoldReason` enum looks like:
      ```rust
      pub enum RuntimeHoldReason {
      
          #[codec(index = 32u8)]
          Preimage(pallet_preimage::HoldReason),
      
          #[codec(index = 38u8)]
          Nis(pallet_nis::HoldReason),
      
          #[codec(index = 42u8)]
          StateTrieMigration(pallet_state_trie_migration::HoldReason),
      }
      ```
      
      - composite enum `RuntimeHoldReason` variant count is detected as `3`
      - we set `type MaxHolds = ConstU32<3>`
      - `pallet_balances::integrity_test` is ok with `3`(at least 3)
      
      However, the real problem can occur in a live runtime where some
      functionality might stop working. This is due to a total of 5 distinct
      hold reasons (for pallets with multi-instance support, it is even more),
      and not all of them can be used because of an incorrect `MaxHolds`,
      which is deemed acceptable according to the `integrity_test`:
        ```
        // pseudo-code - if we try to call all of these:
      
      T::Currency::hold(&pallet_nis::HoldReason::NftReceipt.into(),
      &nft_owner, deposit)?;
      T::Currency::hold(&pallet_preimage::HoldReason::Preimage.into(),
      &nft_owner, deposit)?;
      
      T::Currency::hold(&pallet_state_trie_migration::HoldReason::SlashForContinueMigrate.into(),
      &nft_owner, deposit)?;
      
        // With `type MaxHolds = ConstU32<3>` these two will fail
      
      T::Currency::hold(&pallet_state_trie_migration::HoldReason::SlashForMigrateCustomTop.into(),
      &nft_owner, deposit)?;
      
      T::Currency::hold(&pallet_state_trie_migration::HoldReason::SlashForMigrateCustomChild.into(),
      &nft_owner, deposit)?;
        ```  
      
      
      ## Solutions
      
      A macro `#[pallet::*]` expansion is extended of `VariantCount`
      implementation for the `#[pallet::composite_enum]` enum type. This
      expansion generates the `VariantCount` implementation for pallets'
      `HoldReason`, `FreezeReason`, `LockId`, and `SlashReason`. Enum variants
      must be plain enum values without fields to ensure a deterministic
      count.
      
      The composite runtime enum, `RuntimeHoldReason` and
      `RuntimeFreezeReason`, now sets `VariantCount::VARIANT_COUNT` as the sum
      of pallets' enum `VariantCount::VARIANT_COUNT`:
      ```rust
      #[frame_support::pallet(dev_mode)]
      mod module_single_instance {
      
      	#[pallet::composite_enum]
      	pub enum HoldReason {
      		ModuleSingleInstanceReason1,
      		ModuleSingleInstanceReason2,
      	}
      ...
      }
      
      #[frame_support::pallet(dev_mode)]
      mod module_multi_instance {
      
      	#[pallet::composite_enum]
      	pub enum HoldReason<I: 'static = ()> {
      		ModuleMultiInstanceReason1,
      		ModuleMultiInstanceReason2,
      		ModuleMultiInstanceReason3,
      	}
      ...
      }
      
      
      impl self::sp_api_hidden_includes_construct_runtime::hidden_include::traits::VariantCount
          for RuntimeHoldReason
      {
          const VARIANT_COUNT: u32 = 0
              + module_single_instance::HoldReason::VARIANT_COUNT
              + module_multi_instance::HoldReason::<module_multi_instance::Instance1>::VARIANT_COUNT
              + module_multi_instance::HoldReason::<module_multi_instance::Instance2>::VARIANT_COUNT
              + module_multi_instance::HoldReason::<module_multi_instance::Instance3>::VARIANT_COUNT;
      }
      ```
      
      In addition, `MaxHolds` is removed (as suggested
      [here](https://github.com/paritytech/polkadot-sdk/pull/2657#discussion_r1443324573))
      from `pallet_balances`, and its `Holds` are now bounded to
      `RuntimeHoldReason::VARIANT_COUNT`. Therefore, there is no need to let
      the runtime specify `MaxHolds`.
      
      
      ## For reviewers
      
      Relevant changes can be found here:
      - `substrate/frame/support/procedural/src/lib.rs` 
      -  `substrate/frame/support/procedural/src/pallet/parse/composite.rs`
      -  `substrate/frame/support/procedural/src/pallet/expand/composite.rs`
      -
      `substrate/frame/support/procedural/src/construct_runtime/expand/composite_helper.rs`
      -
      `substrate/frame/support/procedural/src/construct_runtime/expand/hold_reason.rs`
      -
      `substrate/frame/support/procedural/src/construct_runtime/expand/freeze_reason.rs`
      - `substrate/frame/support/src/traits/misc.rs`
      
      And the rest of the files is just about removed `MaxHolds` from
      `pallet_balances`
      
      ## Next steps
      
      Do the same for `MaxFreezes`
      https://github.com/paritytech/polkadot-sdk/issues/2997.
      
      ---------
      
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      Co-authored-by: default avatarDónal Murray <[email protected]>
      Co-authored-by: default avatargupnik <[email protected]>
      bb8ddc46
  12. Jan 26, 2024
  13. Jan 24, 2024
    • dependabot[bot]'s avatar
      Bump arbitrary from 1.3.0 to 1.3.2 (#3037) · b57e53dc
      dependabot[bot] authored
      
      
      Bumps [arbitrary](https://github.com/rust-fuzz/arbitrary) from 1.3.0 to
      1.3.2.
      <details>
      <summary>Changelog</summary>
      <p><em>Sourced from <a
      href="https://github.com/rust-fuzz/arbitrary/blob/main/CHANGELOG.md">arbitrary's
      changelog</a>.</em></p>
      <blockquote>
      <h2>1.3.2</h2>
      <p>Released 2023-10-30.</p>
      <h3>Added</h3>
      <ul>
      <li>Added <code>Arbitrary</code> implementations for
      <code>Arc&lt;[T]&gt;</code> and
      <code>Rc&lt;[T]&gt;</code>. <a
      href="https://redirect.github.com/rust-fuzz/arbitrary/pull/160">#160</a></li>
      </ul>
      <hr />
      <h2>1.3.1</h2>
      <p>Released 2023-10-11.</p>
      <h3>Fixed</h3>
      <ul>
      <li>Fixed an issue with generating collections of collections in
      <code>arbitrary_take_rest</code> where
      <code>&lt;Vec&lt;Vec&lt;u8&gt;&gt;&gt;::arbitrary_take_rest</code> would
      never
      generate <code>vec![vec![]]</code> for example. See
      <a
      href="https://redirect.github.com/rust-fuzz/arbitrary/pull/159">#159</a>
      for details.</li>
      </ul>
      <hr />
      </blockquote>
      </details>
      <details>
      <summary>Commits</summary>
      <ul>
      <li><a
      href="https://github.com/rust-fuzz/arbitrary/commit/66e75c5bf57275d400d3ebc746e0cee4f6ff9596"><code>66e75c5</code></a>
      Bump to version 1.3.1</li>
      <li><a
      href="https://github.com/rust-fuzz/arbitrary/commit/04054dfa1a0f07b233db0581c2d61615df737ade"><code>04054df</code></a>
      Merge pull request <a
      href="https://redirect.github.com/rust-fuzz/arbitrary/issues/160">#160</a>
      from kpreid/arcslice</li>
      <li><a
      href="https://github.com/rust-fuzz/arbitrary/commit/ef5dff63e4f3079acc6455445f0a8080d4857813"><code>ef5dff6</code></a>
      Implement <code>Arbitrary</code> for <code>Arc\&lt;[A]&gt;</code> and
      <code>Rc\&lt;[A]&gt;</code>.</li>
      <li><a
      href="https://github.com/rust-fuzz/arbitrary/commit/b3e8342ea8dc8437aff3d3a1f5b95b7c02bf57f5"><code>b3e8342</code></a>
      Bump to version 1.3.1</li>
      <li><a
      href="https://github.com/rust-fuzz/arbitrary/commit/c1fa740bb777940bda77a4154d035805b4ecce5b"><code>c1fa740</code></a>
      Merge pull request <a
      href="https://redirect.github.com/rust-fuzz/arbitrary/issues/159">#159</a>
      from fitzgen/arbitrary-take-rest-and-collections-of-c...</li>
      <li><a
      href="https://github.com/rust-fuzz/arbitrary/commit/f19fd7a512fe953e902954d01fe046475d8f01a7"><code>f19fd7a</code></a>
      Add clippy allow for existing code running afoul of new clippy lint</li>
      <li><a
      href="https://github.com/rust-fuzz/arbitrary/commit/27560f182b5f0feb8dbd70791cbadd6fbd622411"><code>27560f1</code></a>
      Fix <code>Unstructured::arbitrary_take_rest_iter</code> for collections
      of collections</li>
      <li><a
      href="https://github.com/rust-fuzz/arbitrary/commit/80d6bfe5e8c864a05ed8c1f0a107bca632ea8c61"><code>80d6bfe</code></a>
      Merge pull request <a
      href="https://redirect.github.com/rust-fuzz/arbitrary/issues/157">#157</a>
      from jyn514/ip-addr</li>
      <li><a
      href="https://github.com/rust-fuzz/arbitrary/commit/7d3364edb6a39554c4b97f0d0548289f001121fe"><code>7d3364e</code></a>
      impl Arbitrary for IpAddr</li>
      <li><a
      href="https://github.com/rust-fuzz/arbitrary/commit/0bdbec8a9fdf19a18e6cb8ffe4022b9a6a588cf2"><code>0bdbec8</code></a>
      Merge pull request <a
      href="https://redirect.github.com/rust-fuzz/arbitrary/issues/151">#151</a>
      from Ekleog-NEAR/patch-2</li>
      <li>Additional commits viewable in <a
      href="https://github.com/rust-fuzz/arbitrary/compare/v1.3.0...v1.3.2">compare
      view</a></li>
      </ul>
      </details>
      <br />
      
      
      [![Dependabot compatibility
      score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=arbitrary&package-manager=cargo&previous-version=1.3.0&new-version=1.3.2)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
      
      Dependabot will resolve any conflicts with this PR as long as you don't
      alter it yourself. You can also trigger a rebase manually by commenting
      `@dependabot rebase`.
      
      [//]: # (dependabot-automerge-start)
      [//]: # (dependabot-automerge-end)
      
      ---
      
      <details>
      <summary>Dependabot commands and options</summary>
      <br />
      
      You can trigger Dependabot actions by commenting on this PR:
      - `@dependabot rebase` will rebase this PR
      - `@dependabot recreate` will recreate this PR, overwriting any edits
      that have been made to it
      - `@dependabot merge` will merge this PR after your CI passes on it
      - `@dependabot squash and merge` will squash and merge this PR after
      your CI passes on it
      - `@dependabot cancel merge` will cancel a previously requested merge
      and block automerging
      - `@dependabot reopen` will reopen this PR if it is closed
      - `@dependabot close` will close this PR and stop Dependabot recreating
      it. You can achieve the same result by closing it manually
      - `@dependabot show <dependency name> ignore conditions` will show all
      of the ignore conditions of the specified dependency
      - `@dependabot ignore <dependency name> major version` will close this
      group update PR and stop Dependabot creating any more for the specific
      dependency's major version (unless you unignore this specific
      dependency's major version or upgrade to it yourself)
      - `@dependabot ignore <dependency name> minor version` will close this
      group update PR and stop Dependabot creating any more for the specific
      dependency's minor version (unless you unignore this specific
      dependency's minor version or upgrade to it yourself)
      - `@dependabot ignore <dependency name>` will close this group update PR
      and stop Dependabot creating any more for the specific dependency
      (unless you unignore this specific dependency or upgrade to it yourself)
      - `@dependabot unignore <dependency name>` will remove all of the ignore
      conditions of the specified dependency
      - `@dependabot unignore <dependency name> <ignore condition>` will
      remove the ignore condition of the specified dependency and ignore
      conditions
      
      
      </details>
      
      Signed-off-by: default avatardependabot[bot] <[email protected]>
      Co-authored-by: default avatardependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
      b57e53dc
    • Just van Stam's avatar
      Transactional processing for XCM (#1222) · 50eb12cf
      Just van Stam authored
      
      
      Moved from: https://github.com/paritytech/polkadot/pull/6951
      
      closes https://github.com/paritytech/polkadot-sdk/issues/490
      
      - [x] update cumulus
      
      --- 
      This PR introduces transactional processing of certain xcm instructions.
      For the list of instructions checkout
      https://github.com/paritytech/polkadot-sdk/issues/490. The transactional
      processing is implemented as an xcm-executor config item. The two
      implementations in this PR are `FrameTransactionalProcessor` and `()`.
      The `()` implementation does no transactional processing. Each
      implementation of the `ProcessTransaction` trait has an
      `IS_TRANSACTIONAL` const that tells the XCVM if transactional processing
      is actually implemented. If Transactional processing is implemented,
      changes to touched registers should also be rolled back to prevent
      inconsistencies.
      
      
      Note for reviewers:
      Check out the following safety assumption:
      https://github.com/paritytech/polkadot-sdk/pull/1222/files#diff-4effad7d8c1c9de19fd27e18661cbf2128c8718f3b2420a27d2f816e0749ea53R30
      
      ---------
      
      Co-authored-by: default avatarKeith Yeung <[email protected]>
      Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
      Co-authored-by: command-bot <>
      50eb12cf
  14. Jan 22, 2024
  15. Jan 18, 2024
  16. 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
  17. Dec 20, 2023
    • Dónal Murray's avatar
      Fix clippy lints behind feature gates and add new CI step all features (#2569) · d68868f6
      Dónal Murray authored
      
      
      Many clippy lints usually enforced by `-Dcomplexity` and `-Dcorrectness`
      are not caught by CI as they are gated by `features`, like
      `runtime-benchmarks`, while the clippy CI job runs with only the default
      features for all targets.
      
      This PR also adds a CI step to run clippy with `--all-features` to
      ensure the code quality is maintained behind feature gates from now on.
      
      To improve local development, clippy lints are downgraded to warnings,
      but they still will result in an error at CI due to the `-Dwarnings`
      rustflag.
      
      ---------
      
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      d68868f6
  18. Dec 14, 2023
    • Francisco Aguirre's avatar
      Add FungibleAdapter (#2684) · 10a91f82
      Francisco Aguirre authored
      In the move from the old `Currency` traits to the new `fungible/s`
      family of traits, we already had the `FungiblesAdapter` and
      `NonFungiblesAdapter` for multiple fungible and non fungible assets
      respectively. However, for handling only one fungible asset, we were
      missing a `FungibleAdapter`, and so used the old `CurrencyAdapter`
      instead. This PR aims to fill in that gap, and provide the new adapter
      for more updated examples.
      
      I marked the old `CurrencyAdapter` as deprecated as part of this PR, and
      I'll change it to the new `FungibleAdapter` in a following PR.
      The two stages are separated so as to not bloat this PR with some name
      fixes in tests.
      
      ---------
      
      Co-authored-by: command-bot <>
      10a91f82
  19. Dec 13, 2023
  20. Nov 28, 2023
  21. Nov 21, 2023
    • Francisco Aguirre's avatar
      Different XCM builders, default one requires fee payment (#2253) · b3841b6b
      Francisco Aguirre authored
      Adding on top of the new builder pattern for creating XCM programs, I'm
      adding some more APIs:
      
      ```rust
      let paying_fees: Xcm<()> = Xcm::builder() // Only allow paying for fees
        .withdraw_asset() // First instruction has to load the holding register
        .buy_execution() // Second instruction has to be `buy_execution`
        .build();
      
      let paying_fees_invalid: Xcm<()> = Xcm::builder()
        .withdraw_asset()
        .build(); // Invalid, need to pay for fees
      
      let not_paying_fees: Xcm<()> = Xcm::builder_unpaid()
        .unpaid_execution() // Needed
        .withdraw_asset()
        .deposit_asset()
        .build();
      
      let all_goes: Xcm<()> = Xcm::builder_unsafe() // You can do anything
        .withdraw_asset()
        .deposit_asset()
        .build();
      ```
      
      The invalid bits are because the methods don't even exist on the types
      that you'd want to call them on.
      
      ---------
      
      Co-authored-by: command-bot <>
      b3841b6b
  22. Nov 13, 2023
    • Adrian Catangiu's avatar
      pallet-xcm: enhance `reserve_transfer_assets` to support remote reserves (#1672) · 18257373
      Adrian Catangiu authored
      
      
      ## Motivation
      
      `pallet-xcm` is the main user-facing interface for XCM functionality,
      including assets manipulation functions like `teleportAssets()` and
      `reserve_transfer_assets()` calls.
      
      While `teleportAsset()` works both ways, `reserve_transfer_assets()`
      works only for sending reserve-based assets to a remote destination and
      beneficiary when the reserve is the _local chain_.
      
      ## Solution
      
      This PR enhances `pallet_xcm::(limited_)reserve_withdraw_assets` to
      support transfers when reserves are other chains.
      This will allow complete, **bi-directional** reserve-based asset
      transfers user stories using `pallet-xcm`.
      
      Enables following scenarios:
      - transferring assets with local reserve (was previously supported iff
      asset used as fee also had local reserve - now it works in all cases),
      - transferring assets with reserve on destination,
      - transferring assets with reserve on remote/third-party chain (iff
      assets and fees have same remote reserve),
      - transferring assets with reserve different than the reserve of the
      asset to be used as fees - meaning can be used to transfer random asset
      with local/dest reserve while using DOT for fees on all involved chains,
      even if DOT local/dest reserve doesn't match asset reserve,
      - transferring assets with any type of local/dest reserve while using
      fees which can be teleported between involved chains.
      
      All of the above is done by pallet inner logic without the user having
      to specify which scenario/reserves/teleports/etc. The correct scenario
      and corresponding XCM programs are identified, and respectively, built
      automatically based on runtime configuration of trusted teleporters and
      trusted reserves.
      
      #### Current limitations:
      - while `fees` and "non-fee" `assets` CAN have different reserves (or
      fees CAN be teleported), the remaining "non-fee" `assets` CANNOT, among
      themselves, have different reserve locations (this is also implicitly
      enforced by `MAX_ASSETS_FOR_TRANSFER=2`, but this can be safely
      increased in the future).
      - `fees` and "non-fee" `assets` CANNOT have **different remote**
      reserves (this could also be supported in the future, but adds even more
      complexity while possibly not being worth it - we'll see what the future
      holds).
      
      Fixes https://github.com/paritytech/polkadot-sdk/issues/1584
      Fixes https://github.com/paritytech/polkadot-sdk/issues/2055
      
      ---------
      
      Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
      Co-authored-by: default avatarBranislav Kontur <[email protected]>
      18257373
  23. Nov 08, 2023
    • Francisco Aguirre's avatar
      XCM builder pattern (#2107) · 0524aa51
      Francisco Aguirre authored
      
      
      Added a proc macro to be able to write XCMs using the builder pattern.
      This means we go from having to do this:
      
      ```rust
      let message: Xcm<()> = Xcm(vec![
        WithdrawAsset(assets),
        BuyExecution { fees: asset, weight_limit: Unlimited },
        DepositAsset { assets, beneficiary },
      ]);
      ```
      
      to this:
      
      ```rust
      let message: Xcm<()> = Xcm::builder()
        .withdraw_asset(assets)
        .buy_execution(asset, Unlimited),
        .deposit_asset(assets, beneficiary)
        .build();
      ```
      
      ---------
      
      Co-authored-by: default avatarKeith Yeung <[email protected]>
      Co-authored-by: command-bot <>
      0524aa51
  24. Oct 24, 2023
    • Kian Paimani's avatar
      Ensure correct variant count in `Runtime[Hold/Freeze]Reason` (#1900) · 35eb133b
      Kian Paimani authored
      
      
      closes https://github.com/paritytech/polkadot-sdk/issues/1882
      
      ## Breaking Changes
      
      This PR introduces a new item to `pallet_balances::Config`:
      
      ```diff
      trait Config {
      ++    type RuntimeFreezeReasons;
      }
      ```
      
      This value is only used to check it against `type MaxFreeze`. A similar
      check has been added for `MaxHolds` against `RuntimeHoldReasons`, which
      is already given to `pallet_balances`.
      
      In all contexts, you should pass the real `RuntimeFreezeReasons`
      generated by `construct_runtime` to `type RuntimeFreezeReasons`. Passing
      `()` would also work, but it would imply that the runtime uses no
      freezes at all.
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      35eb133b
  25. Oct 20, 2023
    • Bastian Köcher's avatar
      `xcm`: Change `TypeInfo::path` to not include `staging` (#1948) · f3bf5c1a
      Bastian Köcher authored
      
      
      The `xcm` crate was renamed to `staging-xcm` to be able to publish it to
      crates.io as someone as squatted `xcm`. The problem with this rename is
      that the `TypeInfo` includes the crate name which ultimately lands in
      the metadata. The metadata is consumed by downstream users like
      `polkadot-js` or people building on top of `polkadot-js`. These people
      are using the entire `path` to find the type in the type registry. Thus,
      their code would break as the type path would now be [`staging_xcm`,
      `VersionedXcm`] instead of [`xcm`, `VersionedXcm`]. This pull request
      fixes this by renaming the path segment `staging_xcm` to `xcm`.
      
      This requires: https://github.com/paritytech/scale-info/pull/197
      
      ---------
      
      Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
      f3bf5c1a
  26. Sep 04, 2023
    • Chevdor's avatar
      Markdown linter (#1309) · a30092ab
      Chevdor authored
      
      
      * Add markdown linting
      
      - add linter default rules
      - adapt rules to current code
      - fix the code for linting to pass
      - add CI check
      
      fix #1243
      
      * Fix markdown for Substrate
      * Fix tooling install
      * Fix workflow
      * Add documentation
      * Remove trailing spaces
      * Update .github/.markdownlint.yaml
      
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      * Fix mangled markdown/lists
      * Fix captalization issues on known words
      a30092ab
  27. Sep 01, 2023
  28. Aug 31, 2023
    • Bastian Köcher's avatar
      Rename `polkadot-parachain` to `polkadot-parachain-primitives` (#1334) · a33d7922
      Bastian Köcher authored
      * Rename `polkadot-parachain` to `polkadot-parachain-primitives`
      
      While doing this it also fixes some last `rustdoc` issues and fixes
      another Cargo warning related to `pallet-paged-list`.
      
      * Fix compilation
      
      * ".git/.scripts/commands/fmt/fmt.sh"
      
      * Fix XCM docs
      
      ---------
      
      Co-authored-by: command-bot <>
      a33d7922
  29. Aug 30, 2023
    • Lulu's avatar
      Rename squatted crates (#1241) · 31c79470
      Lulu authored
      * Rename squatted crates
      
      This commit adds the staging- prefix to squatted crates so we can go forward and publish them to crates.io.
      
      Using the staging- prefix is a temp fix until we decide on replacement names.
      https://forum.parity.io/t/renaming-squated-crates-in-substrate-polkadot-cumulus/1964/6
      
      * Fix test after crate renames
      
      * Update Lockfile
      31c79470
  30. Aug 29, 2023
  31. Aug 28, 2023
  32. Aug 25, 2023
  33. Aug 23, 2023
    • juangirini's avatar
      Companion: restructure macro related exports (#7626) · c4aa18c4
      juangirini authored
      * move RuntimeDebug out of frame_support
      
      * move RuntimeDebug out of frame_support
      
      * fix xcm export
      
      * ".git/.scripts/commands/fmt/fmt.sh"
      
      * fix xcm intefration tests
      
      * fix cargo lock for xcm intefration tests
      
      * wip
      
      * restructure benchmarking macro related exports
      
      * update cargo lock
      
      ---------
      
      Co-authored-by: parity-processbot <>
      c4aa18c4
  34. Aug 16, 2023
  35. Aug 14, 2023
  36. Aug 04, 2023