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

Introduce the ContractCaller<AbiName> type #1187

Merged
merged 16 commits into from
Apr 8, 2022
Merged

Conversation

sezna
Copy link
Contributor

@sezna sezna commented Apr 7, 2022

This unblocks adding a layer of abstraction around abi casting and using ContractIds for that. Closes #947, and I think that's the only issue for this?

  • Allow for ABI names to be passed by argument into functions
  • Allow for the ContractCaller<_> type to have a dynamic ABI return (since it's all in the type system anyway)

Associated fixes:

  1. Node dependencies would only check for one level of dependence, but not dependees of dependees.
  2. Abi casts did not have their node dependencies checked.
  3. Abi types also did not have their node dependencies checked.
  4. Remove OwnedCallPath

Extra notes

ABI types are kind of weird. ABI casts and contract caller types are entirely known at compile time and zero-sized at runtime. So, the type system kind of "solves" these expressions (i.e. constantly evaluates them). This is because we need to know all of the details of the ABI at codegen time in order to properly format the CALL opcode and the data it needs.

This PR makes three main concessions for handling ABIs as expressions: parsing of contract caller types, the AbiName expression and some type-engine logic around ContractCallers. The type engine logic is a best attempt at what seems "sensible" for the type system to do, given the special-caseness of these types.

@adlerjohn adlerjohn added compiler General compiler. Should eventually become more specific as the issue is triaged language feature Core language features visible to end users labels Apr 7, 2022
@sezna sezna marked this pull request as ready for review April 8, 2022 00:20
nfurfaro
nfurfaro previously approved these changes Apr 8, 2022
Copy link
Contributor

@nfurfaro nfurfaro left a comment

Choose a reason for hiding this comment

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

Looks good, mostly focused on how a sway dev would use this and I like it.

otrho
otrho previously approved these changes Apr 8, 2022
@sezna sezna merged commit cda4808 into master Apr 8, 2022
@sezna sezna deleted the sezna/contract-caller-type branch April 8, 2022 03:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler General compiler. Should eventually become more specific as the issue is triaged language feature Core language features visible to end users
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Consider whether the ContractCaller type name should be exposed in Sway
5 participants