-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Make hooks and call attributes optional in pallet macro #8853
Conversation
Follow up is to clean any empty call or hooks in existing pallets :) |
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.
Very clean! Would be nice to see empty hooks, call in FRAME pallets also removed.
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.
maybe it is better not to generate any Call enum when user doesn't requires it. from construct_runtime point of view I think the call enum should be optional.
But I'm ok to have an empty Call enum generated.
@thiolliere So the reason why I didn't opt for not generating a Call enum is because the expanded code looked as if other code was dependent on it. I just tried applying the following change and it indeed gave me compiler errors: diff --git a/frame/support/procedural/src/pallet/expand/call.rs b/frame/support/procedural/src/pallet/expand/call.rs
index 0d28f5583..aa21576bd 100644
--- a/frame/support/procedural/src/pallet/expand/call.rs
+++ b/frame/support/procedural/src/pallet/expand/call.rs
@@ -15,20 +15,16 @@
// See the License for the specific language governing permissions and
// limitations under the License.
-use crate::pallet::{Def, parse::call::CallDef};
+use crate::pallet::Def;
use frame_support_procedural_tools::clean_type_string;
use syn::spanned::Spanned;
/// * Generate enum call and implement various trait on it.
/// * Implement Callable and call_function on `Pallet`
pub fn expand_call(def: &mut Def) -> proc_macro2::TokenStream {
- let empty_call;
let call = match def.call.as_ref() {
Some(call) => call,
- None => {
- empty_call = CallDef::empty(def.pallet_struct.attr_span);
- &empty_call
- }
+ None => return proc_macro2::TokenStream::new(),
};
let frame_support = &def.frame_support;
let frame_system = &def.frame_system; Errors:
|
this work to me: diff --git a/frame/support/procedural/src/pallet/expand/call.rs b/frame/support/procedural/src/pallet/expand/call.rs
index 0d28f55839..e5cf2c848b 100644
--- a/frame/support/procedural/src/pallet/expand/call.rs
+++ b/frame/support/procedural/src/pallet/expand/call.rs
@@ -22,12 +22,10 @@ use syn::spanned::Spanned;
/// * Generate enum call and implement various trait on it.
/// * Implement Callable and call_function on `Pallet`
pub fn expand_call(def: &mut Def) -> proc_macro2::TokenStream {
- let empty_call;
let call = match def.call.as_ref() {
Some(call) => call,
None => {
- empty_call = CallDef::empty(def.pallet_struct.attr_span);
- &empty_call
+ return Default::default()
}
};
let frame_support = &def.frame_support;
diff --git a/frame/support/test/tests/pallet_instance.rs b/frame/support/test/tests/pallet_instance.rs
index 846a96a237..08fd636bf6 100644
--- a/frame/support/test/tests/pallet_instance.rs
+++ b/frame/support/test/tests/pallet_instance.rs
@@ -306,8 +306,8 @@ frame_support::construct_runtime!(
Instance1Example: pallet::<Instance1>::{
Pallet, Call, Event<T>, Config, Storage, Inherent, Origin<T>, ValidateUnsigned
},
- Example2: pallet2::{Pallet, Call, Event<T>, Config<T>, Storage},
- Instance1Example2: pallet2::<Instance1>::{Pallet, Call, Event<T>, Config<T>, Storage},
+ Example2: pallet2::{Pallet, Event<T>, Config<T>, Storage},
+ Instance1Example2: pallet2::<Instance1>::{Pallet, Event<T>, Config<T>, Storage},
}
); Pallet without call needs not to have the |
Ah ok, looks like the errors come from importing a non-existent Call part. EDIT: Actually, now that I think about it, what's the best way of producing an error message for users trying to use the Call enum in the |
Okay, so let me take a step back and think about the workflow of a FRAME developer. Suppose that my requirements at the moment required me to create a new pallet that doesn't contain any calls. Right now, I still have to write an empty implementation under the If we were to not generate the So I guess the question would be whether this is a good default to have. I can definitely see it being a sensible default to not generate unnecessary code, but I'm just wondering if this would come at the expense of development friction. (Ideally speaking, this problem would be solved by #8084 where we would have the logic to decide whether or not to generate the |
I agree, there is a tradeoff between:
So I'm ok to generate an empty Call generated 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.
still minor doc comment #8853 (comment) #8853 (comment)
But it is good to me
bot merge |
Trying merge. |
) * Make #[pallet::hooks] optional * Make #[pallet::call] optional * Remove unused imports * Update UI test expectations * Update UI test expectations * Remove unnecessary HooksDef::empty method * Remove unnecessary CallDef::empty method * Clarify what would happen when no call or hooks are specified in a pallet
Fixes #8725.