Construct Runtime v2

[gupnik]

Moved from paritytech/substrate#14788

---

Fixes #232

This PR introduces outer-macro approach for construct_runtime as discussed in the linked issue. It looks like the following:

#[frame_support::runtime]
mod runtime {
	#[runtime::runtime]
        #[runtime::derive(
		RuntimeCall,
		RuntimeEvent,
		RuntimeError,
		RuntimeOrigin,
		RuntimeFreezeReason,
		RuntimeHoldReason,
		RuntimeSlashReason,
		RuntimeLockId,
                RuntimeTask,
	)]
	pub struct Runtime;

	#[runtime::pallet_index(0)]
	pub type System = frame_system;

	#[runtime::pallet_index(1)]
	pub type Timestamp = pallet_timestamp;

	#[runtime::pallet_index(2)]
	pub type Aura = pallet_aura;

	#[runtime::pallet_index(3)]
	pub type Grandpa = pallet_grandpa;

	#[runtime::pallet_index(4)]
	pub type Balances = pallet_balances;

	#[runtime::pallet_index(5)]
	pub type TransactionPayment = pallet_transaction_payment;

	#[runtime::pallet_index(6)]
	pub type Sudo = pallet_sudo;

	// Include the custom logic from the pallet-template in the runtime.
	#[runtime::pallet_index(7)]
	pub type TemplateModule = pallet_template;
}

Features

• #[runtime::runtime] attached to a struct defines the main runtime
• #[runtime::derive] attached to this struct defines the types generated by runtime
• #[runtime::pallet_index] must be attached to a pallet to define its index
• #[runtime::disable_call] can be optionally attached to a pallet to disable its calls
• #[runtime::disable_unsigned] can be optionally attached to a pallet to disable unsigned calls
• A pallet instance can be defined as TemplateModule: pallet_template<Instance>
• An optional attribute can be defined as #[frame_support::runtime(legacy_ordering)] to ensure that the order of hooks is same as the order of pallets (and not based on the pallet_index). This is to support legacy runtimes and should be avoided for new ones.

Todo

• Update the latest syntax in kitchensink and tests
• Update UI tests
• Docs

Extension

• Abstract away the Executive similar to Abstract away the executive substrate#14742
• Optionally avoid the need to specify all runtime types (TBD)

[gilescope]

I'd like to see that we fully respect the ordering based on pallet-index. I.e. the order of AllPallets tuple etc. should be driven off pallet-index rather than having some things sorted by pallet-index and some by lexical. It would be a breaking change but the current mixture of orderings is a footgun.

[KiChjang]

Could we in fact use #[derive] directly and remove #[frame::derive]? Feels like we can replace it with derive macros.

[gupnik]

Could we in fact use #[derive] directly and remove #[frame::derive]? Feels like we can replace it with derive macros.

I saw a couple of issues with that:

1. They won't be able to access outside info (for now it's just the struct Runtime but we will probably have more down the line like Executive, etc.)
2. Each of them would need to parse the Pallets struct with both intermediate and final expansion (using tt_default_parts). That might increase the build time and is probably unneccessary?

[sam0x17]

1. They won't be able to access outside info (for now it's just the struct Runtime but we will probably have more down the line like Executive, etc.)

Well we're in an outer macro pattern already so it doesn't have to be a real derive macro, it's just syntactic sugar. You could have something in construct_runtime_v2 that looks for #[derive()] containing this, pulls it out of the list of derives for that item, and then expands accordingly

[sam0x17]

Looking great, very cool this is happening, few comments and things to discuss 👍🏻

[gupnik]

Quick question, Does that new syntax let me define a generic type on the Runtime?

// pub struct Runtime;
pub struct Runtime<T>(core::marker::PhantomData<T>);

This could be handy in tests to easily test various associated types

impl<T> Config for Runtime<T> {
    type Foo = T;
}

Not sure I completely follow as Runtime is supposed to be a concrete type that provides an implementation for all pallet configs.

What would be an example of the associated type that you want to test here?

[pgherveou]

Not sure I completely follow as Runtime is supposed to be a concrete type that provides an implementation for all pallet configs.

What would be an example of the associated type that you want to test here?

I mean the runtime would be concrete type such as Runtime<()>
I recently stumbled upon this code that creates a test runtime inside a macro. The only reason this macro exists instead of calling it directly is to let the user specify a custom ChainExtension type. Thus I was wondering if this could be avoided with v2

[gupnik]

Not sure I completely follow as Runtime is supposed to be a concrete type that provides an implementation for all pallet configs.
What would be an example of the associated type that you want to test here?

I mean the runtime would be concrete type such as Runtime<()> I recently stumbled upon this code that creates a test runtime inside a macro. The only reason this macro exists instead of calling it directly is to let the user specify a custom ChainExtension type. Thus I was wondering if this could be avoided with v2

Thanks - I think this is a very specific use-case that should probably be handled the way it's done currently?

[ggwpez]

Can we still mark this as experimental by gating it behind that feature flag?
Just until we tested it on Rococo/Westend to be sure that it works.

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/parity-tech-update-for-march/7226/1