1. Apr 24, 2024
  2. Apr 17, 2024
  3. Apr 04, 2024
  4. Apr 02, 2024
    • Dastan's avatar
      migrations: prevent accidentally using unversioned migrations instead of... · e5427969
      Dastan authored
      migrations: prevent accidentally using unversioned migrations instead of `VersionedMigration` (#3835)
      
      closes #1324 
      
      #### Problem
      Currently, it is possible to accidentally use inner unversioned
      migration instead of `VersionedMigration` since both implement
      `OnRuntimeUpgrade`.
      
      #### Solution
      
      With this change, we make it clear that value of `Inner` is not intended
      to be used directly. It is achieved by bounding `Inner` to new trait
      `UncheckedOnRuntimeUpgrade`, which has the same interface (except
      `unchecked_` prefix) as `OnRuntimeUpgrade`.
      
      #### `try-runtime` functions
      
      Since developers can implement `try-runtime` for `Inner` value in
      `VersionedMigration` and have custom logic for it, I added the same
      `try-runtime` functions to `UncheckedOnRuntimeUpgrade`. I looked for a
      ways to not duplicate functions, but couldn't find anything that doesn't
      significantly change the codebase. So I would appreciate If you have any
      suggestions to improve this
      
      cc @liamaharon
      
       @xlc 
      
      polkadot address: 16FqwPZ8GRC5U5D4Fu7W33nA55ZXzXGWHwmbnE1eT6pxuqcT
      
      ---------
      
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      e5427969
    • Serban Iorga's avatar
      Align dependencies with `parity-bridges-common` (#3937) · 8e95a3e1
      Serban Iorga authored
      Working towards migrating the `parity-bridges-common` repo inside
      `polkadot-sdk`. This PR upgrades some dependencies in order to align
      them with the versions used in `parity-bridges-common`
      
      Related to
      https://github.com/paritytech/parity-bridges-common/issues/2538
      8e95a3e1
    • Sam Johnson's avatar
      Update derive syn parse 0.2.0 (+ docify) (#3920) · 9a62de27
      Sam Johnson authored
      
      
      derive-syn-parse v0.2.0 came out recently which (finally) adds support
      for syn 2x.
      
      Upgrading to this will remove many of the places where syn 1x was still
      compiling alongside syn 2x in the polkadot-sdk workspace.
      
      This also upgrades `docify` to 0.2.8 which is the version that upgrades
      derive-syn-pasre to 0.2.0.
      
      Additionally, this consolidates the `docify` versions in the repo to all
      use the latest, and in one case upgrades to the 0.2x syntax where 0.1.x
      was still being used.
      
      ---------
      
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      9a62de27
  5. 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
  6. Mar 17, 2024
  7. Mar 15, 2024
  8. Mar 13, 2024
  9. Mar 05, 2024
    • Kian Paimani's avatar
      Repot all templates into a single directory (#3460) · 4c810609
      Kian Paimani authored
      The first step towards
      https://github.com/paritytech/polkadot-sdk/issues/3155
      
      Brings all templates under the following structure
      
      ```
      templates
      |   parachain
      |   |   polkadot-launch
      |   |   runtime              --> parachain-template-runtime
      |   |   pallets              --> pallet-parachain-template
      |   |   node                 --> parachain-template-node
      |   minimal
      |   |   runtime              --> minimal-template-runtime
      |   |   pallets              --> pallet-minimal-template
      |   |   node                 --> minimal-template-node
      |   solochain
      |   |   runtime              --> solochain-template-runtime
      |   |   pallets              --> pallet-template (the naming is not consistent here)
      |   |   node                 --> solochain-template-node
      ```
      
      The only note-worthy changes in this PR are: 
      
      - More `Cargo.toml` fields are forwarded to use the one from the
      workspace.
      - parachain template now has weights and benchmarks
      - adds a shell pallet to the minimal template
      - remove a few unused deps 
      
      
      A list of possible follow-ups: 
      
      - [ ] Unify READMEs, create a parent README for all
      - [ ] remove references to `docs.substrate.io` in templates
      - [ ] make all templates use `#[derive_impl]`
      - [ ] update and unify all licenses
      - [ ] Remove polkadot launch, use
      https://github.com/paritytech/polkadot-sdk/blob/35349df993ea2e7c4769914ef5d199e787b23d4c/cumulus/zombienet/examples/small_network.toml
      instead.
      4c810609
  10. 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
  11. Mar 02, 2024
    • gupnik's avatar
      Remove `as frame_system::DefaultConfig` from the required syntax in `derive_impl` (#3505) · cdc8d197
      gupnik authored
      Step in https://github.com/paritytech/polkadot-sdk/issues/171
      
      This PR removes the need to specify `as [disambiguation_path]` for cases
      where the trait definition resides within the same scope as default impl
      path.
      
      For example, in the following macro invocation
      ```rust
      #[derive_impl(frame_system::config_preludes::TestDefaultConfig as frame_system::DefaultConfig)]
      impl frame_system::Config for Runtime {
         ...
      }
      ```
      the trait `DefaultConfig` lies within the `frame_system` scope and
      `TestDefaultConfig` impls the `DefaultConfig` trait. Using this
      information, we can compute the disambiguation path internally, thus
      removing the need of an explicit specification.
      
      In cases where the trait lies outside this scope, we would still need to
      specify it explicitly, but this should take care of most (if not all)
      uses of `derive_impl` within FRAME's context.
      cdc8d197
  12. Feb 28, 2024
  13. Feb 21, 2024
  14. Feb 12, 2024
  15. Feb 08, 2024
    • Oliver Tale-Yazdi's avatar
      [FRAME] Parameters pallet (#2061) · e53ebd8c
      Oliver Tale-Yazdi authored
      Closes #169  
      
      Fork of the `orml-parameters-pallet` as introduced by
      https://github.com/open-web3-stack/open-runtime-module-library/pull/927
      
      
      (cc @xlc)
      It greatly changes how the macros work, but keeps the pallet the same.
      The downside of my code is now that it does only support constant keys
      in the form of types, not value-bearing keys.
      I think this is an acceptable trade off, give that it can be used by
      *any* pallet without any changes.
      
      The pallet allows to dynamically set parameters that can be used in
      pallet configs while also restricting the updating on a per-key basis.
      The rust-docs contains a complete example.
      
      Changes:
      - Add `parameters-pallet`
      - Use in the kitchensink as demonstration
      - Add experimental attribute to define dynamic params in the runtime.
      - Adding a bunch of traits to `frame_support::traits::dynamic_params`
      that can be re-used by the ORML macros
      
      ## Example
      
      First to define the parameters in the runtime file. The syntax is very
      explicit about the codec index and errors if there is no.
      ```rust
      #[dynamic_params(RuntimeParameters, pallet_parameters::Parameters::<Runtime>))]
      pub mod dynamic_params {
      	use super::*;
      
      	#[dynamic_pallet_params]
      	#[codec(index = 0)]
      	pub mod storage {
      		/// Configures the base deposit of storing some data.
      		#[codec(index = 0)]
      		pub static BaseDeposit: Balance = 1 * DOLLARS;
      
      		/// Configures the per-byte deposit of storing some data.
      		#[codec(index = 1)]
      		pub static ByteDeposit: Balance = 1 * CENTS;
      	}
      
      	#[dynamic_pallet_params]
      	#[codec(index = 1)]
      	pub mod contracts {
      		#[codec(index = 0)]
      		pub static DepositPerItem: Balance = deposit(1, 0);
      
      		#[codec(index = 1)]
      		pub static DepositPerByte: Balance = deposit(0, 1);
      	}
      }
      ```
      
      Then the pallet is configured with the aggregate:  
      ```rust
      impl pallet_parameters::Config for Runtime {
      	type AggregratedKeyValue = RuntimeParameters;
      	type AdminOrigin = EnsureRootWithSuccess<AccountId, ConstBool<true>>;
      	...
      }
      ```
      
      And then the parameters can be used in a pallet config:
      ```rust
      impl pallet_preimage::Config for Runtime {
      	type DepositBase = dynamic_params::storage::DepositBase;
      }
      ```
      
      A custom origin an be defined like this:  
      ```rust
      pub struct DynamicParametersManagerOrigin;
      
      impl EnsureOriginWithArg<RuntimeOrigin, RuntimeParametersKey> for DynamicParametersManagerOrigin {
      	type Success = ();
      
      	fn try_origin(
      		origin: RuntimeOrigin,
      		key: &RuntimeParametersKey,
      	) -> Result<Self::Success, RuntimeOrigin> {
      		match key {
      			RuntimeParametersKey::Storage(_) => {
      				frame_system::ensure_root(origin.clone()).map_err(|_| origin)?;
      				return Ok(())
      			},
      			RuntimeParametersKey::Contract(_) => {
      				frame_system::ensure_root(origin.clone()).map_err(|_| origin)?;
      				return Ok(())
      			},
      		}
      	}
      
      	#[cfg(feature = "runtime-benchmarks")]
      	fn try_successful_origin(_key: &RuntimeParametersKey) -> Result<RuntimeOrigin, ()> {
      		Ok(RuntimeOrigin::Root)
      	}
      }
      ```
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarNikhil Gupta <[email protected]>
      Co-authored-by: default avatarKian Paimani <[email protected]>
      Co-authored-by: command-bot <>
      e53ebd8c
  16. Feb 06, 2024
    • Squirrel's avatar
      sp-std -> core (#3199) · bc2e5e1f
      Squirrel authored
      First in a series of PRs that reduces our use of sp-std with a view to
      deprecating it.
      
      This is just looking at /substrate and moving some of the references
      from `sp-std` to `core`.
      These particular changes should be uncontroversial.
      
      Where macros are used `::core` should be used to remove any ambiguity.
      
      part of https://github.com/paritytech/polkadot-sdk/issues/2101
      bc2e5e1f
  17. 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
  18. Jan 26, 2024
  19. Jan 22, 2024
  20. Dec 15, 2023
  21. Dec 13, 2023
  22. Dec 08, 2023
    • Sam Johnson's avatar
      Tasks: general system for recognizing and executing service work (#1343) · ac3f14d2
      Sam Johnson authored
      `polkadot-sdk` version of original tasks PR located here:
      https://github.com/paritytech/substrate/pull/14329
      
      Fixes #206
      
      ## Status
      - [x] Generic `Task` trait
      - [x] `RuntimeTask` aggregated enum, compatible with
      `construct_runtime!`
      - [x] Casting between `Task` and `RuntimeTask` without needing `dyn` or
      `Box`
      - [x] Tasks Example pallet
      - [x] Runtime tests for Tasks example pallet
      - [x] Parsing for task-related macros
      - [x] Retrofit parsing to make macros optional
      - [x] Expansion for task-related macros
      - [x] Adds support for args in tasks
      - [x] Retrofit tasks example pallet to use macros instead of manual
      syntax
      - [x] Weights
      - [x] Cleanup
      - [x] UI tests
      - [x] Docs
      
      ## Target Syntax
      Adapted from
      https://github.com/paritytech/polkadot-sdk/issues/206#issue-1865172283
      
      
      
      ```rust
      // NOTE: this enum is optional and is auto-generated by the other macros if not present
      #[pallet::task]
      pub enum Task<T: Config> {
          AddNumberIntoTotal {
              i: u32,
          }
      }
      
      /// Some running total.
      #[pallet::storage]
      pub(super) type Total<T: Config<I>, I: 'static = ()> =
      StorageValue<_, (u32, u32), ValueQuery>;
      
      /// Numbers to be added into the total.
      #[pallet::storage]
      pub(super) type Numbers<T: Config<I>, I: 'static = ()> =
      StorageMap<_, Twox64Concat, u32, u32, OptionQuery>;
      
      #[pallet::tasks_experimental]
      impl<T: Config<I>, I: 'static> Pallet<T, I> {
      	/// Add a pair of numbers into the totals and remove them.
      	#[pallet::task_list(Numbers::<T, I>::iter_keys())]
      	#[pallet::task_condition(|i| Numbers::<T, I>::contains_key(i))]
      	#[pallet::task_index(0)]
      	pub fn add_number_into_total(i: u32) -> DispatchResult {
      		let v = Numbers::<T, I>::take(i).ok_or(Error::<T, I>::NotFound)?;
      		Total::<T, I>::mutate(|(total_keys, total_values)| {
      			*total_keys += i;
      			*total_values += v;
      		});
      		Ok(())
      	}
      }
      ```
      
      ---------
      
      Co-authored-by: default avatarNikhil Gupta <[email protected]>
      Co-authored-by: default avatarkianenigma <[email protected]>
      Co-authored-by: Nikhil Gupta <>
      Co-authored-by: default avatarGavin Wood <[email protected]>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatargupnik <[email protected]>
      ac3f14d2
  23. Dec 01, 2023
  24. Nov 30, 2023
  25. Nov 28, 2023
  26. Nov 13, 2023
    • gupnik's avatar
      Adds syntax for marking calls feeless (#1926) · 60c77a2e
      gupnik authored
      Fixes https://github.com/paritytech/polkadot-sdk/issues/1725
      
      
      
      This PR adds the following changes:
      1. An attribute `pallet::feeless_if` that can be optionally attached to
      a call like so:
      ```rust
      #[pallet::feeless_if(|_origin: &OriginFor<T>, something: &u32| -> bool {
      	*something == 0
      })]
      pub fn do_something(origin: OriginFor<T>, something: u32) -> DispatchResult {
           ....
      }
      ```
      The closure passed accepts references to arguments as specified in the
      call fn. It returns a boolean that denotes the conditions required for
      this call to be "feeless".
      
      2. A signed extension `SkipCheckIfFeeless<T: SignedExtension>` that
      wraps a transaction payment processor such as
      `pallet_transaction_payment::ChargeTransactionPayment`. It checks for
      all calls annotated with `pallet::feeless_if` to see if the conditions
      are met. If so, the wrapped signed extension is not called, essentially
      making the call feeless.
      
      In order to use this, you can simply replace your existing signed
      extension that manages transaction payment like so:
      ```diff
      - pallet_transaction_payment::ChargeTransactionPayment<Runtime>,
      + pallet_skip_feeless_payment::SkipCheckIfFeeless<
      +	Runtime,
      +	pallet_transaction_payment::ChargeTransactionPayment<Runtime>,
      + >,
      ```
      
      ### Todo
      - [x] Tests
      - [x] Docs
      - [x] Prdoc
      
      ---------
      
      Co-authored-by: Nikhil Gupta <>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      60c77a2e
  27. Nov 09, 2023
  28. Oct 31, 2023
  29. Oct 27, 2023
    • juangirini's avatar
      feat: FRAME umbrella crate. (#1337) · 43415ef5
      juangirini authored
      ### Original PR https://github.com/paritytech/substrate/pull/14137
      
      This PR brings in the first version of the "_`frame` umbrella crate_".
      This crate is intended to serve two purposes:
      
      1. documentation
      2. easier development with frame. Ideally, we want most users to be able
      to build a frame-based pallet and runtime using just `frame` (plus
      `scale-codec` and `scale-info`).
      
      The crate is not finalized and is not yet intended for external use.
      Therefore, the version is set to `0.0.1-dev`, this PR is `silent`, and
      the entire crate is hidden behind the `experimental` flag. The main
      intention in merging it early on is to be able to iterate on it in the
      rest of
      [`developer-hub`](https://github.com/paritytech/polkadot-sdk-docs/)
      efforts.
      
      The public API of the `frame` crate is at the moment as follows: 
      
      ```
      pub mod frame
      pub use frame::log
      pub use frame::pallet
      pub mod frame::arithmetic
      pub use frame::arithmetic::<<sp_arithmetic::*>>
      pub use frame::arithmetic::<<sp_arithmetic::traits::*>>
      pub mod frame::deps
      pub use frame::deps::codec
      pub use frame::deps::frame_executive
      pub use frame::deps::frame_support
      pub use frame::deps::frame_system
      pub use frame::deps::scale_info
      pub use frame::deps::sp_api
      pub use frame::deps::sp_arithmetic
      pub use frame::deps::sp_block_builder
      pub use frame::deps::sp_consensus_aura
      pub use frame::deps::sp_consensus_grandpa
      pub use frame::deps::sp_core
      pub use frame::deps::sp_inherents
      pub use frame::deps::sp_io
      pub use frame::deps::sp_offchain
      pub use frame::deps::sp_runtime
      pub use frame::deps::sp_std
      pub use frame::deps::sp_version
      pub mod frame::derive
      pub use frame::derive::CloneNoBound
      pub use frame::derive::Debug
      pub use frame::derive::Debug
      pub use frame::derive::DebugNoBound
      pub use frame::derive::Decode
      pub use frame::derive::Decode
      pub use frame::derive::DefaultNoBound
      pub use frame::derive::Encode
      pub use frame::derive::Encode
      pub use frame::derive::EqNoBound
      pub use frame::derive::PartialEqNoBound
      pub use frame::derive::RuntimeDebug
      pub use frame::derive::RuntimeDebugNoBound
      pub use frame::derive::TypeInfo
      pub use frame::derive::TypeInfo
      pub mod frame::prelude
      pub use frame::prelude::<<frame_support::pallet_prelude::*>>
      pub use frame::prelude::<<frame_system::pallet_prelude::*>>
      pub use frame::prelude::<<sp_std::prelude::*>>
      pub use frame::prelude::CloneNoBound
      pub use frame::prelude::Debug
      pub use frame::prelude::Debug
      pub use frame::prelude::DebugNoBound
      pub use frame::prelude::Decode
      pub use frame::prelude::Decode
      pub use frame::prelude::DefaultNoBound
      pub use frame::prelude::Encode
      pub use frame::prelude::Encode
      pub use frame::prelude::EqNoBound
      pub use frame::prelude::PartialEqNoBound
      pub use frame::prelude::RuntimeDebug
      pub use frame::prelude::RuntimeDebugNoBound
      pub use frame::prelude::TypeInfo
      pub use frame::prelude::TypeInfo
      pub use frame::prelude::frame_system
      pub mod frame::primitives
      pub use frame::primitives::BlakeTwo256
      pub use frame::primitives::H160
      pub use frame::primitives::H256
      pub use frame::primitives::H512
      pub use frame::primitives::Hash
      pub use frame::primitives::Keccak256
      pub use frame::primitives::U256
      pub use frame::primitives::U512
      pub mod frame::runtime
      pub mod frame::runtime::apis
      pub use frame::runtime::apis::<<frame_system_rpc_runtime_api::*>>
      pub use frame::runtime::apis::<<sp_api::*>>
      pub use frame::runtime::apis::<<sp_block_builder::*>>
      pub use frame::runtime::apis::<<sp_consensus_aura::*>>
      pub use frame::runtime::apis::<<sp_consensus_grandpa::*>>
      pub use frame::runtime::apis::<<sp_offchain::*>>
      pub use frame::runtime::apis::<<sp_session::runtime_api::*>>
      pub use frame::runtime::apis::<<sp_transaction_pool::runtime_api::*>>
      pub use frame::runtime::apis::ApplyExtrinsicResult
      pub use frame::runtime::apis::CheckInherentsResult
      pub use frame::runtime::apis::InherentData
      pub use frame::runtime::apis::OpaqueMetadata
      pub use frame::runtime::apis::impl_runtime_apis
      pub use frame::runtime::apis::sp_api
      pub mod frame::runtime::prelude
      pub use frame::runtime::prelude::<<frame_executive::*>>
      pub use frame::runtime::prelude::ConstBool
      pub use frame::runtime::prelude::ConstI128
      pub use frame::runtime::prelude::ConstI16
      pub use frame::runtime::prelude::ConstI32
      pub use frame::runtime::prelude::ConstI64
      pub use frame::runtime::prelude::ConstI8
      pub use frame::runtime::prelude::ConstU128
      pub use frame::runtime::prelude::ConstU16
      pub use frame::runtime::prelude::ConstU32
      pub use frame::runtime::prelude::ConstU64
      pub use frame::runtime::prelude::ConstU8
      pub use frame::runtime::prelude::NativeVersion
      pub use frame::runtime::prelude::RuntimeVersion
      pub use frame::runtime::prelude::construct_runtime
      pub use frame::runtime::prelude::create_runtime_str
      pub use frame::runtime::prelude::derive_impl
      pub use frame::runtime::prelude::frame_support
      pub use frame::runtime::prelude::ord_parameter_types
      pub use frame::runtime::prelude::parameter_types
      pub use frame::runtime::prelude::runtime_version
      pub mod frame::runtime::testing_prelude
      pub use frame::runtime::testing_prelude::BuildStorage
      pub use frame::runtime::testing_prelude::Storage
      pub mod frame::runtime::types_common
      pub type frame::runtime::types_common::AccountId = <<frame::runtime::types_common::Signature as sp_runtime::traits::Verify>::Signer as sp_runtime::traits::IdentifyAccount>::AccountId
      pub type frame::runtime::types_common::BlockNumber = u32
      pub type frame::runtime::types_common::BlockOf<T, Extra> = sp_runtime::generic::block::Block<sp_runtime::generic::header::Header<frame::runtime::types_common::BlockNumber, sp_runtime::traits::BlakeTwo256>, sp_runtime::generic::unchecked_extrinsic::UncheckedExtrinsic<sp_runtime::multiaddress::MultiAddress<frame::runtime::types_common::AccountId, ()>, <T as frame_system::pallet::Config>::RuntimeCall, frame::runtime::types_common::Signature, Extra>>
      pub type frame::runtime::types_common::OpaqueBlock = sp_runtime::generic::block::Block<sp_runtime::generic::header::Header<frame::runtime::types_common::BlockNumber, sp_runtime::traits::BlakeTwo256>, sp_runtime::OpaqueExtrinsic>
      pub type frame::runtime::types_common::Signature = sp_runtime::MultiSignature
      pub type frame::runtime::types_common::SystemSignedExtensionsOf<T> = (frame_system::extensions::check_non_zero_sender::CheckNonZeroSender<T>, frame_system::extensions::check_spec_version::CheckSpecVersion<T>, frame_system::extensions::check_tx_version::CheckTxVersion<T>, frame_system::extensions::check_genesis::CheckGenesis<T>, frame_system::extensions::check_mortality::CheckMortality<T>, frame_system::extensions::check_nonce::CheckNonce<T>, frame_system::extensions::check_weight::CheckWeight<T>)
      pub mod frame::testing_prelude
      pub use frame::testing_prelude::<<frame_executive::*>>
      pub use frame::testing_prelude::<<frame_system::mocking::*>>
      pub use frame::testing_prelude::BuildStorage
      pub use frame::testing_prelude::ConstBool
      pub use frame::testing_prelude::ConstI128
      pub use frame::testing_prelude::ConstI16
      pub use frame::testing_prelude::ConstI32
      pub use frame::testing_prelude::ConstI64
      pub use frame::testing_prelude::ConstI8
      pub use frame::testing_prelude::ConstU128
      pub use frame::testing_prelude::ConstU16
      pub use frame::testing_prelude::ConstU32
      pub use frame::testing_prelude::ConstU64
      pub use frame::testing_prelude::ConstU8
      pub use frame::testing_prelude::NativeVersion
      pub use frame::testing_prelude::RuntimeVersion
      pub use frame::testing_prelude::Storage
      pub use frame::testing_prelude::TestState
      pub use frame::testing_prelude::assert_err
      pub use frame::testing_prelude::assert_err_ignore_postinfo
      pub use frame::testing_prelude::assert_error_encoded_size
      pub use frame::testing_prelude::assert_noop
      pub use frame::testing_prelude::assert_ok
      pub use frame::testing_prelude::assert_storage_noop
      pub use frame::testing_prelude::construct_runtime
      pub use frame::testing_prelude::create_runtime_str
      pub use frame::testing_prelude::derive_impl
      pub use frame::testing_prelude::frame_support
      pub use frame::testing_prelude::frame_system
      pub use frame::testing_prelude::if_std
      pub use frame::testing_prelude::ord_parameter_types
      pub use frame::testing_prelude::parameter_types
      pub use frame::testing_prelude::runtime_version
      pub use frame::testing_prelude::storage_alias
      pub mod frame::traits
      pub use frame::traits::<<frame_support::traits::*>>
      pub use frame::traits::<<sp_runtime::traits::*>>
      ```
      
      ---
      
      The road to full stabilization is
      
      - [ ] https://github.com/paritytech/polkadot-sdk/issues/127
      
      
      - [ ] have a more intentional version bump, as opposed to the current bi
      weekly force-major-bump
      - [ ] revise the internal API of `frame`, especially what goes into the
      `prelude`s.
      - [ ] migrate all internal pallets and runtime to use `frame`
      
      ---------
      
      Co-authored-by: default avatarkianenigma <[email protected]>
      Co-authored-by: default avatarKian Paimani <[email protected]>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
      43415ef5
  30. Oct 24, 2023
  31. 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
  32. Oct 17, 2023
  33. Oct 11, 2023
    • gupnik's avatar
      Fixes path issue in derive-impl (#1823) · 294e9983
      gupnik authored
      Needs https://github.com/sam0x17/macro_magic/pull/13
      
      The associated PR allows the export of tokens from macro_magic at the
      specified path. This fixes the path issue in derive-impl. Now, we can
      import the default config using the standard rust syntax:
      
      ```rust
      use frame_system::config_preludes::TestDefaultConfig;
      
      [derive_impl(TestDefaultConfig as frame_system::DefaultConfig)]
      impl frame_system::DefaultConfig for Test {
         //....
      }
      ```
      294e9983
  34. Oct 01, 2023
  35. Sep 29, 2023
  36. Sep 18, 2023
  37. 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