Implement 'transactional' annotation for runtime functions.

[shaunxw]

Provides a convenient way to make runtime functions atomic. All changes to storage performed by the annotated function are discarded if it returns Err, or committed if Ok.

Closes #6587

TODO

• Support dispatchable calls definition in decl_module.

[shawntabrizi]

yeah, makes perfect sense. does it work in the macro?

[shaunxw]

yeah, makes perfect sense. does it work in the macro?

Thanks for reviewing. You mean the decl_module macro? It would take some efforts to integrate it into decl_module, which has quite a few pattern matching branches. (The integration should be similar with weight attribute support.)

I didn't include the decl_module support in this PR, to make the idea easier to review and got feedback early. Would make another PR for decl_module support if this one accepted. :]

[shawntabrizi]

@shaopengw its just a little strange to me to merge this PR when it is not usable.

[shaunxw]

@shaopengw its just a little strange to me to merge this PR when it is not usable.

My original thought was normal functions outside decl_module support is also an use case. But yeah it's only fully usable if macro support included. I'll keep working and include the macro part in this one.

[shaunxw]

Updated. It works in the decl_module macro now. :]

[gui1117]

seems to be related to #2782 also

[shawntabrizi]

I see an error if you flip the order of #[transactional] and #[weight = ..] that it fails to compile.

[gui1117]

indeed the attribute order is:

		$(#[doc = $doc_attr:tt])*
		#[weight = $weight:expr]
		$(#[$fn_attr:meta])*

so doc then weight then function attribute.

[gui1117]

So at least doc of decl_module should now state that attribute on function are:

• optional doc attributes,
• then weight attributes,
• then optional function attributes, those function attributes will be written only on the dispatchable function implemented on Module, not on the Call enum variant.

At some point we could also do it more like the try! macro, instead of attribute macro:

let my_ok_result = try_or_rollback!(
    ensure_origin(origin)?;
    ...
);

[gui1117]

if attribute order is not too magical for user, implementation is ok to me.

[shawntabrizi]

if attribute order is not too magical for user, implementation is ok to me.

If this is okay from your perspective, it is okay to me too. I just thought it would not be expected that attribute order should matter. (Since it doesnt for normal rust)

[shaunxw]

Actually, before this PR, doc and weight also have magical order. I tried different solutions, but cannot find a proper way to make the order flexible for user, due to macro_rules limitations. Maybe the procedural macro attribute refactor in #5678 could solve it?

[shawntabrizi]

its okay with me :)

we can improve in another point in time :)

[kianenigma]

@shaopengw thanks! the build error should be irrelevant. If possible merge master one last time and we're good to go.

[shaunxw]

@kianenigma Thanks for reviewing. Updated :)

[gui1117]

yes looks good to me, and doc should be fine

[gui1117]

bot merge

[ghost]

Trying merge.