-
Notifications
You must be signed in to change notification settings - Fork 2.6k
construct_runtime auto pallet parts: allow pallets to expand { Event, Call... }
automatically.
#6494
Conversation
2616950
to
6dddfb8
Compare
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.
Nice! 👍
frame/treasury/src/lib.rs
Outdated
@@ -111,6 +111,16 @@ type BalanceOf<T> = <<T as Trait>::Currency as Currency<<T as frame_system::Trai | |||
type PositiveImbalanceOf<T> = <<T as Trait>::Currency as Currency<<T as frame_system::Trait>::AccountId>>::PositiveImbalance; | |||
type NegativeImbalanceOf<T> = <<T as Trait>::Currency as Currency<<T as frame_system::Trait>::AccountId>>::NegativeImbalance; | |||
|
|||
#[macro_export] | |||
macro_rules! auto_construct_runtime { |
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.
Nice idea, as you already said, it would be nice to replace this with
construct_runtime_args!( Module, Call, Storage, Config, Event<T> )
construct_runtime_args
can be replaced with a better name.
And we should not require |
Yes so final syntax should be something like: construct_runtime!(.... { System: frame_system, Treasury: frame_treasury, OldSyntax: frame_old::{Module...} }) and for pallet side: decl_construct_runtime_args!( Module, Call, Storage, Config, Event<T> ) Though one thing is that construct_runtime_args doesn't really support |
I have something prepared for this already :D I need to revive the branch and open a Pr ;) |
I added better syntax and also now that construct_runtime is smaller I think we can use it in test instead of using impl_outer_*. |
4ddf971
to
8e71a22
Compare
I updated the PR to only contains the changes in frame-support frame-system and primitive, the generalized usage of it is moved to another branch https://github.com/paritytech/substrate/compare/gui-automatic-construct-runtime...gui-automatic-construct-runtime-usage?expand=1 where I implemented for all pallets, and most tests except non-obvious ones (i.e. system, balance, contract, and some other (just grep |
All limitations have been solved:
|
@@ -163,6 +229,12 @@ fn decl_outer_inherent<'a>( | |||
}) | |||
}); | |||
quote!( | |||
// Prevent UncheckedExtrinsic to print unused warning. | |||
const _: () = { |
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 see this pattern in the expansions of derive macros of codec as well, what is the purpose? is the keyword __hidden_use_unchecked_extrinsic
used anywhere now?
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.
no, keyword __hidden_use_unchecked_extrinsic
is not used anywhere, warpping in const is a pattern used by many derive macro, for instance serde.
I think the main advantage is that it makes type __hidden_use_unchecked_extrinsic
unavailable in doc and rust error will not recommand it.
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.
But if the type alias is not even accessible and used anywhere, I don't see how it is used.
For example I've this and it makes sense:
const _: () { impl Something for SomethingElse { ... } }
but something like:
const _: () = { type __unused_alias = Foo; }
I don't get.
Unless is __hidden_use_unchecked_extrinsic
used in the other branch? Asking because I couldn't find any usage here.
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.
this is just to // Prevent UncheckedExtrinsic to print unused warning.
so I have const _: () = { #[allow(unused)] type __unused_alias = Foo; }
UncheckedExtrinsic is unused if there is no inherent.
@@ -1375,3 +1377,14 @@ impl<T: Trait> Lookup for ChainContext<T> { | |||
<T::Lookup as StaticLookup>::lookup(s) | |||
} | |||
} | |||
|
|||
/// An implementation of `sp_runtime::traits::Block` to be used in test. | |||
pub type MockBlock<T> = generic::Block< |
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.
This does not seem used to me, else why not feature gate it to test or at least std?
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.
in this following PR https://github.com/paritytech/substrate/compare/gui-automatic-construct-runtime...gui-automatic-construct-runtime-usage?expand=1
I used it a lot for pallet mocks.
I guess we could feature get but I don't see strong reason not to have in no_std as well. some people could make use of it for no_std mock.
One main issue of this PR is that pallet can remove their call or their origin and it changes the outer call and outer origin types. |
closing because of inactivity. |
NOTE: I still think this makes definition of construct_runtime really easier. Either we should do like this or we could make new attribute macro implement an empty Event, Inherent, ValidateUnsigned, ... and make pallet in construct_runtime having by default all attribute (which is simpler). |
Yeah, I'm also in for this. One question, did your version supported negation? So let's say I have a pallet where I expose a |
I didn't supported negation but indeed after macro attribute I can work on this |
Hope to see the PR be reincarnated soon. |
This PR is to be followed by its generalized usage in substrate https://github.com/paritytech/substrate/compare/gui-automatic-construct-runtime...gui-automatic-construct-runtime-usage?expand=1
Description
Introduce new decl_construct_runtime_args so:
pallet declare construct_runtime args with:
decl_construct_runtime_args!( Module, Config<T>, Storage.. )
and then construct_runtime can be called as such:
this will expand to
if there is multiple pallet in the same crate, a unique id must be provided, this unique id is only internally used:
decl_construct_runtime_args!(#[unique_id = _2] Module, Config<T>, Storage.. )
see https://github.com/paritytech/substrate/pull/6494/files#diff-a8500018e076e76e369b45df6010dd2d
Goal
simplify construct_runtime so: less error prone construct_runtime and more usable in tests instead of impl_outer_* which are not consistent and very hacky.
General notes:
multiple pallet per crate is still doable
no breaking change, runtime can still define the part themself
This makes construct_runtime smaller, I think it should replace impl_outer_* in tests. Thus test environment are more consistent. (some helpful type has been added to system for this purpose)
if you want to see how looks substrate once tests and runtime are moved to new syntax see https://github.com/paritytech/substrate/compare/gui-automatic-construct-runtime...gui-automatic-construct-runtime-usage?expand=1
while implementing decl_construct_runtime_args for pallets I saw that some
Config
were missed.(maybe I could do more sanity check: if
Storage
is provided but notConfig
then decl_construct_runtime_args generate a test thatConfig
is not generated by decl_storage (i.e. decl_storage will provide a function__hidden_has_generated_config
). but this is for another PR and fixed by Move support macros to attribute procedural macros #5678).Move support macros to attribute procedural macros #5678 will implement this macro automatically.
How does it works internally
for the given example
construct_runtime do a preprocessing and expand for each
auto
pallet parts a overarching macro call:Each auto_construct_runtime replace the match of their matching pattern in the following token stream.
Resulting in:
until the expanded construct_runtime call: