Update seal_call to __unstable__ version#960
Conversation
Codecov Report
@@ Coverage Diff @@
## master #960 +/- ##
==========================================
+ Coverage 78.80% 78.83% +0.02%
==========================================
Files 244 244
Lines 9188 9222 +34
==========================================
+ Hits 7241 7270 +29
- Misses 1947 1952 +5
Continue to review full report at Codecov.
|
The coverage reports are broken since quite a while ... |
Robbepop
left a comment
Robbepop
left a comment
There was a problem hiding this comment.
Not a fan of the introduction of Option<ExecutionInput> since we can do better here with a system that relies on already existing compile time information. Also we could better protect against invalid flags.
There was a problem hiding this comment.
To me it looks like it uses the seal_call API correctly. Cannot really comment on the Option situation Robin is raising.
I guess code gen will be changed in a later step to allow for actually setting those flags without going through the CallBuilder?
AFAIK this will change the default behavior of calls to disallow reentering the calling contract. Something to keep in mind.
| pub fn seal_call( | ||
| callee_ptr: Ptr32<[u8]>, | ||
| callee_len: u32, | ||
| gas: u64, | ||
| transferred_value_ptr: Ptr32<[u8]>, | ||
| transferred_value_len: u32, | ||
| input_ptr: Ptr32<[u8]>, | ||
| input_len: u32, | ||
| output_ptr: Ptr32Mut<[u8]>, | ||
| output_len_ptr: Ptr32Mut<u32>, | ||
| ) -> ReturnCode; | ||
|
|
There was a problem hiding this comment.
We drop support for any stable contracts pallet (without having unstable-interface) set. Not saying this is bad. Just raising awareness.
* Update `seal_call` to `__unstable__` version * Add `Debug` derive * Make `cargo-spellcheck` happy * Make `into_u32` take `self` * Update release notes * Fix crate docs link * Use type-system encoded version of empty `ExecutionInput` * Add `const` for getters and setters * Shorten if-branches logic * Update release notes * Remove dead code * Improve release notes
4 participants
Follow-up to paritytech/substrate#8909.