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

chore!: support new encoding schema #2826

Closed
wants to merge 33 commits into from
Closed

Conversation

nedsalk
Copy link
Contributor

@nedsalk nedsalk commented Jul 24, 2024

Note

This PR can't be merged until a new version of forc is released with FuelLabs/sway#6254.


Release notes

In this release, we:

  • Added support for forc 0.63.0

Summary

This PR adds support for the new abi format. The ABI now contains concreteTypes and metadataTypes. A concrete type can be either a built-in type (e.g. u8) or it can be a specific instance of a metadata type. Functions, configurables, logged types, message types - they all now reference only concrete types.

The way I've gone about implementing this in the abi-coder is that I created a ResolvableType for each metadata type, which are then used to get ResolvedTypes for every specific concrete type usage in function inputs, outputs, configurables, etc. This ResolvedType contains all the information necessary to use in coders the same way ResolvedAbiType previously did.

The benefit of this approach is that I could reuse the same concept of ResolvableType and ResolvedType in abi-typegen. Because typegen already interpreted the ABI in such a way previously (this is where I got the inspiration from), it was relatively easy to plug the new solution in.

Once abi-coder and abi-typegen become one package in #2346, the code duplication will cease to exist.

I couldn't go with reusing the old ResolvedAbiType approach in abi-typegen because it approached the ABI in a fundamentally different way. Instead of creating all types and then plugging in specific (concrete) implementations of those types, it would create a tree just for the specific type implementation it was given, which isn't the proper approach for typegen which first lists all the types (generic and non-generic) and then references them in function inputs, outputs, and configurables.

Breaking Changes

TBD once reviews are done.

Checklist

  • I addedtests to prove my changes
  • I updated — all the necessary docs
  • I reviewed — the entire PR myself, using the GitHub UI
  • I described — all breaking changes and the Migration Guide

@nedsalk nedsalk added the chore Issue is a chore label Jul 24, 2024
@nedsalk nedsalk self-assigned this Jul 24, 2024
@arboleya arboleya mentioned this pull request Jul 24, 2024
4 tasks
@nedsalk nedsalk added the p0 label Jul 24, 2024
@nedsalk nedsalk force-pushed the ns/new-encoding-concept branch 2 times, most recently from eba2294 to 416f3f0 Compare July 25, 2024 08:22
internal/forc/lib/shared.js Dismissed Show dismissed Hide dismissed
@nedsalk
Copy link
Contributor Author

nedsalk commented Jul 30, 2024

Closing this PR in favor of #2856 and we'll later use it when we approach the abi (typegen + coder) holistically in a rewrite.

@nedsalk nedsalk closed this Jul 30, 2024
@nedsalk nedsalk mentioned this pull request Jul 30, 2024
4 tasks
@arboleya arboleya deleted the ns/new-encoding-concept branch July 30, 2024 10:28
@nedsalk nedsalk mentioned this pull request Aug 1, 2024
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore Issue is a chore
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Typegen generating invalid types with Scripts and Predicates Adapt ABI format to new specification
3 participants