-
Notifications
You must be signed in to change notification settings - Fork 443
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Return LangError
s from constructors
#1504
Conversation
These can't return dispatch errors atm. I may want to clean up how this is done later.
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.
Looks good, we may want to resolve the type of the ReturnValueSpec
to be non optional before merging.
}; | ||
|
||
<<#storage_ident as ::ink::reflect::ContractConstructorDecoder>::Type | ||
as ::ink::reflect::ExecuteDispatchable>::execute_dispatchable(dispatchable) |
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.
Looking at this control flow again: from a readability perspective, I wonder whether it would be better to have this inside the Ok
arm of the match. It seems unusual because of the semantics of return_value
returning immediately !
. A casual reader might expect this statement to always be executed. Just a note for something to consider when we get to refactoring this dispatch logic.
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.
Yeah that seems fair enough. I'll leave it for a follow-up since we'll want to change it for messages too
> | ||
>( | ||
"ink_primitives::ConstructorResult" | ||
) |
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.
I bet we could fit that all on one line to avoid the ugly indentation e.g.
::ink::ConstructorResult<()>>("ink_primitives::ConstructorResult")
) | ||
) | ||
} else { | ||
::core::option::Option::None | ||
::core::option::Option::Some(::ink::metadata::TypeSpec::with_name_str::< |
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.
ReturnTypeSpec
should now always expect a TypeSpec
instead of an Option<TypeSpec>
. There is one other usage to take care of for trait output types.
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.
I don't know enough about all the metadata types to be able to remove this and still get things compiling, so in the interest of time I'm gonna leave it a a follow-up
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.
Opened #1515
Another thing to note is that the contract sizes have gone up very slightly again here: so something to investigate for future betas. e.g. |
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.
Metadata and return_value
invocations look good.
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.
I think we forgot the reversion
I saw a change to unify those cases and get away with a single |
Side effect of this refactoring has been the cancelling out of this size increase:
|
Okay then let's be nice to the compiler and also unify it for the |
The change related to handling The current behaviour of this PR is as follows:
Since the most important thing here are the metadata changes, we could in principle |
I don't get it. When I use the call builder I define myself what I expect to receive. And I would need to define that I get
Shouldn't it be |
What we want to talk about here isn't the When I talk about "normal dispatch" I'm referring to calls that go through something like
If I log the return of the which calls |
Okay I got it. Yes this is a bit more of a high level stuff then. Yes we can leave it that way for the beta.
Yeah those off-chain callers are also not that interesting for ABI. As a matter of fact none of the UIs even displays data coming back from constructors (cause we didn't return anything up until now). We are good here.
This is the callee side. But I thought we are discussing the caller here. How does the caller handle getting a Err(LangError)? |
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.
LGTM. Please check my remaining unresolved comments
.await; | ||
|
||
assert!( | ||
matches!(result, Err(ink_e2e::Error::InstantiateExtrinsic(_))), |
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.
Awesome ❤️
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.
I'm fine to delay the CreateBuilder
changes in #1512 to a subsequent beta
release, based on the philosophy of stablizing the ABI but allowing breaking code changes.
Sorry, maybe I'm missing something - but right now they don't. There are two scenarios:
|
Checked the code. Looks alright. We don't even decode the return buffer for instantiate. So we are safe here. So from my side we can merge this and release the first beta. #1512 is not needed for the beta. |
Maybe it's a naming clash?
This reverts commit cab6c98.
Codecov Report
@@ Coverage Diff @@
## master #1504 +/- ##
==========================================
- Coverage 71.70% 65.85% -5.86%
==========================================
Files 204 204
Lines 6306 6314 +8
==========================================
- Hits 4522 4158 -364
- Misses 1784 2156 +372
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
// NOTE: Right now we can't handle any `LangError` from `instantiate`, we can only tell | ||
// that our contract reverted (i.e we see error from the Contracts pallet). | ||
result.ok().map(|id| ink::ToAccountId::to_account_id(&id)) |
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.
How do you recommend handling instantiating other contracts inside a constructor?
Follow-up to #1450, and closes the constructor part of #1207.
As in #1450, constructors now return a
Result<Constructor::Output, LangError>
which can be handled by callers.
If you're curious, click here for a snippet of the new metadata.
TODOs (Edit: These are gonna be done in #1512)
Add test showing how to handleLangError
ContractRef implementations