-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Proposal: Flatten AllPallets
and similar types
#11813
Conversation
bot rebase |
Rebased |
/cmd queue -c fmt $ |
@kianenigma Could not find start of command (" $ ") |
/cmd queue -c fmt |
@kianenigma Could not find start of command (" $ ") |
/cmd queue -c fmt $ 1 |
@kianenigma https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/1726286 was started for your command Comment |
@kianenigma Command |
|
||
/// All pallets included in the runtime as a nested tuple of types. | ||
/// Excludes the System pallet. | ||
pub type AllPalletsWithoutSystem = ( #all_pallets_without_system ); | ||
pub type AllPalletsWithoutSystem = ( #(#names_without_system),* ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pub type AllPalletsWithoutSystem = ( #(#names_without_system),* ); | |
pub type AllPalletsWithoutSystem = ( #(#all_pallets_without_system),* ); |
pub type AllPalletsWithoutSystemReversed = ( #all_pallets_without_system_reversed ); | ||
pub type AllPalletsWithoutSystemReversed =( #(#names_without_system_reverse),* ); | ||
|
||
/// All pallets included in the runtime as a nested tuple of types in reversed order. | ||
pub type AllPalletsWithSystemReversed = ( #all_pallets_with_system_reversed ); | ||
pub type AllPalletsWithSystemReversed = ( #(#names_reversed),* ); | ||
|
||
/// All pallets included in the runtime as a nested tuple of types in reversed order. | ||
/// With the system pallet first. | ||
pub type AllPalletsReversedWithSystemFirst = ( | ||
#system_pallet, | ||
AllPalletsWithoutSystemReversed | ||
); | ||
pub type AllPalletsReversedWithSystemFirst = ( #(#names_reversed_with_system_first),* ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can probably now get rid of them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would start by marking them as deprecated? or are you sure they are not needed anywhere?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah good idea.
Co-authored-by: Bastian Köcher <[email protected]>
Co-authored-by: Bastian Köcher <[email protected]>
bot rebase |
Rebased |
The CI pipeline was cancelled due to failure one of the required jobs. |
…substrate into kiz-flatten-all-pallets-type
@@ -1,13 +1,13 @@ | |||
error[E0107]: missing generics for trait `Hooks` | |||
--> $DIR/hooks_invalid_item.rs:12:18 | |||
--> tests/pallet_ui/hooks_invalid_item.rs:12:18 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am a little bit unsure about why I had to change this, but I assume it is harmless.
bot merge |
* flratten AllPallets types * feature flag it * fix * fix * fmt * remove todo * Update frame/support/src/traits/metadata.rs Co-authored-by: Bastian Köcher <[email protected]> * Update frame/support/src/migrations.rs Co-authored-by: Bastian Köcher <[email protected]> * fix * mark as deprecated * add docs * fix ui test? * fmt Co-authored-by: parity-processbot <> Co-authored-by: Bastian Köcher <[email protected]>
This pull request has been mentioned on Polkadot Forum. There might be relevant details there: https://forum.polkadot.network/t/polkadot-release-analysis-v0-9-41-v0-9-42/2828/1 |
Currently, all of the types generated via this macro are nested. For example, you have:
As far as I know, the main advantage of this is that we can use recursive implementations in some places. For example,
PalletsInfoAccess
introduced in https://github.com/paritytech/substrate/pull/10053/files is only implemented for(T1, T2)
, and there's no need to generate the code for longer tuples.In fact, if we use only nested tuples, you can probably get away with
impl_trait_for_tuple(2)
for most items that are implemented for all pallets, such asOnInitialize
etc.The problem is: certain traits like
OnInitialize
are perfectly comprehensible both forT
, and(T1, T2, T3)
, and(T1, (T2, T3))
. But, certain traits likePalletInfoAccess
are only comprehensible on individual items, i.e.T
, but not on tuples.And then you have an unfortunate scenario where you want to assert
where T: PalletInfoAccess
, and you know that eachT
does indeed implementPalletInfoAccess
, but if demonstrated as a nested tuple, this does not work.You can see a concrete example of this in what I am trying to do here: https://github.com/paritytech/substrate/pull/10174/files#diff-1c449417be9803cb427eed15d51557931141d47d0047561407f1651d319f7103R183
Lastly, in general, arguing about a flat array of tuples rather then nested is generally easier.