Metadata V15: Expose types for the overarching Call, Event, Error enums

[lexnv]

This PR exposes the overarching types for RuntimeEvent andRuntimeCall and RuntimeError for the V15 metadata.

The RuntimeEvent andRuntimeCall are represented as is.

The code that previously generate the RuntimeEvent is extended to now generate the RuntimeError enum since they share almost 95% of the functionality.

Construct Runtime Changes

Runtimes can be constructed implicitly or explicitly.
To ensure that the Error enum is propagated to the metadata for each pallet that declares one with #[pallet::error] macro the construction of the runtime is changed:

State Machine

The construct_runtime transitioned from an implicit to an explicit state.
For explicit declarations, we are now including the Error<T> part if defined.

# Old declaration
implicit -> explicit

# New declaration
implicit -> explicit -> explicit expanded

This introduces a new state explicit expanded which transforms the construct_runtime in a similar manner.
For optimization purposes, any implicit declaration is transformed into an explicit expanded form (ie if all pallets are declared implicit, then we'll expand the macro only once as before).

The tt_extra_parts is added to each pallet definition and is responsible for creating a token stream of expanded pallet parts:

expanded :: { Error }

This effectively transforms:

# implicit declaration
Balances: frame_balances

# Transformed to explicit declaration
Balances: frame_balances expanded::{} ::{Pallet, Call, ...}

For explicit declarations:

# Explict declaration
Balances: frame_balances ::{Pallet, Call}

# Transformed to explicit expanded declaration
# This exposes by default the `Error` pallet part if defined.
# Pallet parts are collected into the same vector: `Pallet`, `Call`, and `Error`.
Balances: frame_balances expanded::{ Error } ::{Pallet, Call}

polkadot companion: paritytech/polkadot#7401

Depends on: paritytech/frame-metadata#57
Closes paritytech/frame-metadata#43.

// @paritytech/subxt-team

[gui1117]

seems good to me, apart from comments below

[lexnv]

After having a discussion with @bkchr, it is possible to have the RuntimeError without any breaking changes to users that explicitly declare the runtime.

That being said, this PR changes a bit the construct_runtime! logic to add an extra expansion of the pallet parts in case the construct_runtime! is not fully expanded.

The implicit state of pallets: System: frame_system will transition directly to the end state System: expanded::{Pallet, Call...}. The keyword expanded is added to mark the end of the transitions, and users should not bother with this.

The explicit part was previously the final state. Now, explicit parts System: frame_system::{Pallet, Call} will transition similarly to implicit parts to the end state: System: frame_system ::expanded::{Error} :: {Pallet, Call}.
Note that additional parts are now added to the expanded section. We forward currently just the Error iff defined, but could change this in the future to include more parts.

Please let me know what you think of it considering it is touching a bit more places of code now @bkchr, @jsdw , @sam0x17 🙏

[bkchr]

Reviewed most of it, will hopefully do the rest this evening!

[bkchr]

Why do you provide here expanded?

[lexnv]

This would be the "final state" of the construct_runtime!, without this the macro will try to get expanded one more time. And the expansions require the pallets to expose tt_extra_parts macro, and for dummy pallets that's not the case (not sure here if this is constructed with only valid pallets 🤔 )

[bkchr]

Sounds like a bug?

[lexnv]

I've reverted this to remove the expanded word, the output looks similar to before.
Some small differences in how the compiler reports the error, most probably related to the extra expansion

Example

missing_event_generic_on_module_with_instance.rs (this is the entire file)

use frame_support::construct_runtime;

construct_runtime! {
	pub struct Runtime where
		Block = Block,
		NodeBlock = Block,
		UncheckedExtrinsic = UncheckedExtrinsic
	{
		System: system::{Pallet},
		Balance: balances::<Instance1>::{Event},
	}
}

fn main() {}

If we don't add the expanded keyword this would produce:

error[E0433]: failed to resolve: use of undeclared crate or module `balances`
  --> tests/construct_runtime_ui/missing_event_generic_on_module_with_instance.rs:10:12
   |
10 |         Balance: balances::<Instance1> ::{Event},
   |                  ^^^^^^^^ use of undeclared crate or module `balances`

When we would actually expect:

error: Instantiable pallet with no generic `Event` cannot be constructed: pallet `Balance` must have generic `Event`
  --> $DIR/missing_event_generic_on_module_with_instance.rs:10:3
   |
10 |         Balance: balances::<Instance1> ::{Event},
   |         ^^^^^^^

I'm presuming that because the construct_runtime! is not in it's final expression (does not contain the expanded), the macro tries to expand the pallet one more time. In doing so it calls balances::tt_extra_parts!, which does not exist (ie theres no balances module).

The "Instantiable pallet with no generic Event cannot be constructed: pallet Balance must have generic" compile error should be coming from the final step of the construct_runtime! macro. And I think it's not outputted/detected because the missing module error has priority for the compiler 🤔

Let me know if this sounds right :D

[lexnv]

@bkchr would love to get your feedback on the above 🙏

[kianenigma]

@gupnik I suggest you taking a look at the construct_runtime changes. This might also be relevant to paritytech/polkadot-sdk#232.

[lexnv]

bot merge