[FRAME] Simplify pallet config definition: remove RuntimeEvent associated type

[dastansam]

part of #3743

Motivation

This PR removes the need for defining RuntimeEvent in the Config trait of a pallet. It uses associated type bound feature under the hood to make sure that Event of the pallet is convertible to the aggregated runtime event type frame_system::RuntimeEvent.

This is an initial PR for RuntimeEvent type and will be followed with other types, e.g RuntimeCall. As a demo, example pallets' config definition is updated to use this feature.

With this change, we can do this:

#[pallet::config]
pub trait Config: frame_system::Config {
}

instead of this:

#[pallet::config]
pub trait Config: frame_system::Config {
        /// Overarching event type.
       type RuntimeEvent: From<Event<Self>> + IsType<<Self as frame_system::Config>::RuntimeEvent>;
}

or alternatively, it is possible to explicitly define the type bound:

#[pallet::config]
pub trait Config: frame_system::Config<RuntimeEvent: From<Event<Self>>> {
}

polkadot address: 16FqwPZ8GRC5U5D4Fu7W33nA55ZXzXGWHwmbnE1eT6pxuqcT

[bkchr]

Ty for doing this!

[bkchr]

IMO it would be much "cooler" 👀 if the pallet::config macro would auto generate all of these. And then we could put a deprecation warning over RuntimeEvent, RuntimeCall etc inclusion in the Config trait later.

[gui1117]

I agree, for the implementation all pallets except frame-system can bound this From<Event> automatically.

For frame-system pallet, I guess we need something so that the macro can know that the pallet is frame-system, I suggest a new attribute somewhere (maybe on pallet::config) like #[pallet::is_frame_system].
But if you find a better way, please do.

[dastansam]

ok, I have made the changes to automatically append the type bound to system supertrait. I did this on the macro expansion level instead of parsing, since we need to know if the pallet Event struct is actually defined.

For frame-system pallet, I guess we need something so that the macro can know that the pallet is frame-system, I suggest a new attribute somewhere (maybe on pallet::config) like #[pallet::is_frame_system].
But if you find a better way, please do.

For this, I simply opted for checking if the pallet config contains a system supertrait, i.e frame_system::Config. If it doesn't, it's a system pallet.

[dastansam]

@bkchr bunch of CI is failing because they treat the RuntimeEvent deprecation warnings as error. Do you think it's worth fixing all those deprecation warnings in this PR? I thought it would be a lot of changes and also would feel more comfortable doing it once this change is carefully reviewed.

[bkchr]

We should use proc_macro_warning for issuing the warning to the pallet builder. Besides that we should provide an "allow(deprecated)" above the type to not print the warning.

Then we basically need to update all pallets in the repo to accept the deprecated RuntimeEvent. At some later point we then need to remove it. There is sadly no real better way for downstream as removing them at some point.

[bkchr]

We should do what @gui1117 proposed and introduce a frame_system_pallet attribute macro that we will use in frame_system. Every other pallet will then be assumed to not be frame-system.

[gui1117]

Suggested change

	#[pallet::no_default]
	#[pallet::no_default] // optional. `RuntimeEvent` is automatically excluded as well.

[gui1117]

Suggested change

	/// The overarching task type.
	/// The overarching task type. This is coming from the runtime, and cannot have a default.
	/// In general, `Runtime*`-oriented types cannot have a sensible default.