Atomic transaction annotation for dispatchable calls

[shaunxw]

This issue is a syntax proposal to support atomic transaction annotation for dispatchable calls definition in decl_module.

The boilerplate

With nested storage supported #6269 , now transaction rollback on error is possible. A typical atomic dispatch call implementation would be:

use frame_support::storage::{with_transaction, TransactionOutcome};

pub fn my_call(origin) {
        with_transaction(|| {
                // `my_call` implementation
                // -- snip --
                // Finally we have a `Result` of execution as `r`
		if r.is_ok() {
			TransactionOutcome::Commit(res)
		} else {
			TransactionOutcome::Rollback(res)
		}
	})?;
}

This pattern would be repeated every time defining an atomic dispatchable call.

The syntax

To avoid repeating the boilerplate, I propose to add an atomic (or other names if preferred) annotation syntax, which will wrap the implementation in a with_transaction commit/rollback pattern as above. The syntax is like:

#[atomic]
pub fn my_call(origin) {
        // `my_call` implementation
        // -- snip --
}

And expanded as:

use frame_support::storage::{with_transaction, TransactionOutcome};

pub fn my_call(origin) {
        with_transaction(|| {
                let r = {
                        // `my_call` implementation
                        // -- snip --
                };
		if r.is_ok() {
			TransactionOutcome::Commit(res)
		} else {
			TransactionOutcome::Rollback(res)
		}
	})?;
}

[kianenigma]

could be implemented in #5678.

[shaunxw]

could be implemented in #5678.

#5678 looks like a long term refactor, it might take a while before we could use it?

I tried to implement a transactional attribute for runtime functions in #6763 . If it's the right direction, will make another PR to support dispatchable calls in decl_module macro. It should be easy to refactor it as a part of #5678 in the future. cc @thiolliere

[gui1117]

#5678 looks like a long term refactor, it might take a while before we could use it?

Indeed, this is not priority

It should be easy to refactor it as a part of #5678 in the future. cc @thiolliere

Yes, generally speaking code in macro-rules are very easy to factorize when the parser is done.