-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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,
PalletsInfoAccessintroduced 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 asOnInitializeetc.The problem is: certain traits like
OnInitializeare perfectly comprehensible both forT, and(T1, T2, T3), and(T1, (T2, T3)). But, certain traits likePalletInfoAccessare 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 eachTdoes 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.