Skip to content
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

[move-compiler][sui-mode] Add entry function signature checks #12990

Merged
merged 3 commits into from
Jul 19, 2023

Conversation

tnowacki
Copy link
Contributor

@tnowacki tnowacki commented Jul 13, 2023

Description

  • Ported entry function signature checks to the compiler guarded by sui-mode

Test Plan

  • Ported tests

If your changes are not user-facing and not a breaking change, you can skip the following section. Otherwise, please indicate what changed, and then add to the Release Notes section as highlighted during the release process.

Type of Change (Check all that apply)

  • protocol change
  • user-visible impact
  • breaking change for a client SDKs
  • breaking change for FNs (FN binary must upgrade)
  • breaking change for validators or node operators (must upgrade binaries)
  • breaking change for on-chain data layout
  • necessitate either a data wipe or data migration

Release notes

The Sui Move toolchain will now provide diagnostics (in the form of errors) for incorrect entry function signatures at the source language level.

@vercel
Copy link

vercel bot commented Jul 13, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
mysten-ui ❌ Failed (Inspect) Jul 19, 2023 11:49am
6 Ignored Deployments
Name Status Preview Comments Updated (UTC)
explorer ⬜️ Ignored (Inspect) Jul 19, 2023 11:49am
explorer-storybook ⬜️ Ignored (Inspect) Jul 19, 2023 11:49am
multisig-toolkit ⬜️ Ignored (Inspect) Jul 19, 2023 11:49am
sui-kiosk ⬜️ Ignored (Inspect) Jul 19, 2023 11:49am
sui-wallet-kit ⬜️ Ignored (Inspect) Jul 19, 2023 11:49am
wallet-adapter ⬜️ Ignored (Inspect) Jul 19, 2023 11:49am

fn tx_context_kind(sp!(_, last_param_ty_): &Type) -> TxContextKind {
let (is_mut, inner_ty) = match last_param_ty_ {
Type_::Ref(is_mut, inner_ty) => (*is_mut, &inner_ty.value),
_ => return TxContextKind::None,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At this point do we already detect and error on a TxContext by value?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, yeah it could be an interesting warning/error?
But nothing needed at the bytecode level, so this is sort of new for source language.

Comment on lines 161 to 162
let inner_name = match inner_ty {
Type_::Apply(_, sp!(_, n_), _) => n_,
_ => return TxContextKind::None,
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let ... else?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact, would it be crazy to do this all in one let ... else?

let (is_mut, Type_::Apply(_, sp!(_, n_), _) = last_param_ty_ else {
    return TxContextKind::None
}

(Also, what's with the trailing underscores?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A naming pattern I use around the compiler for Spanned<T> items, where I will normally do n @ sp!(loc, n_). Which (for better or for worse) is a pattern I've held onto from OCaml

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And I cannot do 1 let-else because of the Box 💢

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I said it, I knew this was why, I just hoped I was wrong...

}
}

fn entry_return(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we document or link to the documentation for what we expect from a valid entry return type? (TIL we can return drop-able types from an entry functions).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can do it as a separate PR, sure!

@github-actions github-actions bot added the Type: Documentation Improvements or additions to documentation label Jul 18, 2023
@tnowacki tnowacki enabled auto-merge (squash) July 18, 2023 14:13
@tnowacki tnowacki mentioned this pull request Jul 18, 2023
7 tasks
@vercel vercel bot temporarily deployed to Preview – mysten-ui July 19, 2023 11:49 Inactive
@tnowacki tnowacki merged commit b70e12d into MystenLabs:main Jul 19, 2023
@tnowacki tnowacki deleted the sm-typing-1 branch July 19, 2023 12:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Documentation Improvements or additions to documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants