-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
feat!: adding abi
transpiler
#2856
Conversation
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.
🚀 🚢
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.
f019cba
Coverage Report:
Changed Files:
|
readonly type: string; | ||
readonly metadataTypeId: number; | ||
readonly components?: readonly Component[]; | ||
readonly typeParameters?: readonly number[]; |
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.
Is this an array of concrete type indexes or metadata type indexes? It's hard to tell which array this refers to.
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.
It is an array of metadata type ids:
"typeParameters": an array of type metadata declaration ID of the type parameters of the type, if the type is generic, otherwise nonexistent. Each type parameter is a type declaration and is represented as described in Generic Type Parameter.
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.
IDs as in the hashes or the array indexes? Everywhere else, it looks like the hashes are stored as strings. Are these hashes stored as numbers instead or are these array indexes?
The spec itself is unclear on this.
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 type ids are always numbers. On the topic of array indexes, I wouldn't use array indexes for anything; they might correlate with the metadataTypeId
of an entry in the metadataTypes
array, but the spec doesn't define that relationship.
export interface ConcreteType { | ||
readonly type: string; | ||
readonly concreteTypeId: string; | ||
readonly metadataTypeId?: number; |
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.
Per the spec, this should be a string (hash). It would help reduce complexity if this were consistent.
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.
The link you gave us points to this same field the comment is on...
Regardless, the spec says this for concreteType.metadataTypeId
:
"metadataTypeId": the type metadata declaration ID of this type, if the type metadata has components or is generic, otherwise nonexistent.
And it defines metadataType.metadataTypeId
as this:
"metadataTypeId": a unique integer ID.
So this conforms with the specification.
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.
Sorry, updated the link. It also says this:
- _type metadata declaration_: the declaration or definition of a type which can be generic. `struct Foo { .. }` and `struct Bar<T> { .. }` in the example above are both type declarations. The metadata declaration contains component details about the type. And a single _type metadata declaration_ is generated per type, even for generic types.
Which makes it sound like "type metadata declaration ID" is the string hash, not an array index.
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.
The string hashes are exclusively related to concrete types (hashes of their type
property). The spec doesn't mention array indexes in relation to metadataTypeId
s, it just defines them as a field of the object. I wouldn't rely on that correlation to build anything as it might change: a metadata type with id 12
might be put onto index 24
and it would still be spec-compliant.
readonly type: string; | ||
readonly concreteTypeId: string; |
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.
Is type
just the type name, or is it the full type string? i.e. MyStruct
or path::to::MyStruct<T>
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.
It's the full type string. You can find examples lower down in the spec.
export interface AbiFunction { | ||
readonly name: string; | ||
readonly inputs: readonly AbiFunctionInput[]; | ||
readonly output: string; |
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.
Is this string the concrete type hash or the decoded full type string?
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.
It's the concrete type hash. From the spec:
"output": the type concrete declaration hash based ID of the type being returned by the function.
* Upgrading forc to temp branch * Adding ABI transpiler and integrating it with related areas * Updating typegen fixtures * Fixing broken typegen tests; updating outdated IDs * Re-instating the order * Loading forc projects the standard and proper way * Updating coder’s types, regexes, and fixing type matching everywhere * Updating test using callpath-based naming for Option * Fixing test, intercepting ABI loading so it can be transpiled * Adding changeset * Adjusting changeset * Excluding sway-repo source files in `forc:check` script * Ensuring branches are up to date before building * Building internal packages in `--release` mode * Fixing directory path for new build target * Merging duplicated variables, standardizing terminologies * Improving validation to handle strings / non-objects as well * fix: option coder decoding incorrect value (#2870) * Revert "Improving validation to handle strings / non-objects as well" This reverts commit 45f3ef2. * chore: fixing types on OptionCoder * fix: match full qualifying type name with regex * chore: added test groups Co-authored-by: Daniel Bate <djbate23@gmail.com> * chore: revert StructCoder name change --------- Co-authored-by: Daniel Bate <djbate23@gmail.com> * Standardizing timeout limits across workflows * Ignoring `sway-repo`in links check when building things from source * Fixing ignore path * Stop deleting `concreteTypeId`, used in public API * Update .changeset/odd-horses-cheer.md * Ignoring also `fuel-core-repo` for the same reasons as `sway-repo` * Update .changeset/odd-horses-cheer.md * Updating more fixtures * Updating snippet * Fixing random lint warning * Incrasing test timeout limit * Fixing ignored paths * chore!: internalize old `JsonAbi` format (#2862) * use `transpileAbi` in `Interface` * add new interfaces to typegen * no need for `debug` build anymore * fix `getTypegenForcProject` return type * added `as JsonAbi` type assertions to fix type errors * fix typegen tests * rename variable * stop exporting `JsonAbi` from typegen * revert changes that should be in another PR * contttinue exporting * rename to match `master` * fix encode-and-decode test * Renamed `JsonAbiNew` to `JsonAbi` and the old format to `JsonAbiOld` * fix compilation errors * Stop exporting `AbiCoder` and update `encode-and-decode` example * Removed `Interface.findTypeById` method * stop casting `as unknown as JsonAbi` * use `argument` directly * fix import * fix: `Interface.encodeType/decodeType` * Update packages/abi-coder/src/types/JsonAbi.ts Co-authored-by: Peter Smith <peter@blueoceancomputing.co.uk> * Update packages/abi-coder/src/types/JsonAbiNew.ts Co-authored-by: Peter Smith <peter@blueoceancomputing.co.uk> * Update packages/abi-typegen/src/types/interfaces/JsonAbi.ts Co-authored-by: Peter Smith <peter@blueoceancomputing.co.uk> * Update packages/account/test/fuel-wallet-connector.test.ts Co-authored-by: Peter Smith <peter@blueoceancomputing.co.uk> * Update packages/abi-typegen/src/utils/transpile-abi.ts Co-authored-by: Peter Smith <peter@blueoceancomputing.co.uk> * copy/paste transpile-abi * fix compilation error * eslint disable todo type * use `{ transpile: T }` params object * update `encode-and-decode.md` docs * fix: spellcheck * Update apps/docs/src/guide/encoding/encode-and-decode.md Co-authored-by: Anderson Arboleya <anderson@arboleya.me> * Update apps/docs/src/guide/encoding/encode-and-decode.md Co-authored-by: Anderson Arboleya <anderson@arboleya.me> * Update apps/docs/src/guide/encoding/encode-and-decode.md Co-authored-by: Anderson Arboleya <anderson@arboleya.me> --------- Co-authored-by: Anderson Arboleya <anderson@arboleya.me> Co-authored-by: Peter Smith <peter@blueoceancomputing.co.uk> * Getting around non-null assertions * Adjusting changeset * Adjusting scripts * Updating template fixtures/snapshots * Triggering CI * The branch is gone - temporarily switching to `master` * Temporarily patching sway std lib * Temporarily skipping problematic sway projects and related tests * Lintfix - deprecations, types mismatch, and broken imports * DRYing test setup/teardown * Fixing broken tests * Patching base library individually * Unskipping problematic workspace members * Adjusting predicate data handling * Undoing undesired changed * Adjuting more projects * Revert "Temporarily skipping problematic sway projects and related tests" This reverts commit dc054ff. * Formatting * Revert "Temporarily patching sway std lib" This reverts commit 48b0ab3. * Revert "Patching base library individually" This reverts commit b97c944. * Replacing sway `branch` by `0.63.0` version * Update .changeset/odd-horses-cheer.md Co-authored-by: Peter Smith <peter@blueoceancomputing.co.uk> * Updating forc version --------- Co-authored-by: Peter Smith <peter@blueoceancomputing.co.uk> Co-authored-by: Nedim Salkić <nedim.salkic@fuel.sh> Co-authored-by: Daniel Bate <djbate23@gmail.com>
Release notes
In this release, we:
forc
to v0.63.0 & v0.63.1Summary
Given the amount of structural changes we had in the new ABI and the impact it will have on the codebase, and provided the fact we have a lot of technical debt to clear regarding ABI
coder
andtypegen
packages (#1795, #2346, #2686), this proposal aim at releasing the pressure of the moment by transpiling the old format into the new one, while still:Transpilation occurs internally between public and private APIs.
Interface
levelJsonAbi
, and the old one is available asJsonAbiOld
AbiCoder
is no longer exported, and its methods moved toInterface
viaencodeType
/decodeType
(ee734b9)Interface.findTypeById
method in 157bdba because the concept of a type in the new ABI differs from the old one. Whoever wants to get a specific concrete or metadata type can do so directly from the ABI they have on theInterface.jsonAbi
propertySpecial thanks ❤️
Huge shoutout to @nedsalk, who was crucial for this work and ensured everything around this was working as expected everywhere and finalized all the heavy lifting around public vs private APIs via:
JsonAbi
format #2862Also, to @petertonysmith94, for the thorough reviews and additional bug-fixing via:
Breaking Changes
New ABI spec
The SDK now adheres to the new specs introduced via:
Check these out to understand all its changes.
AbiCoder
is no longer available to importThe class
AbiCoder
is no longer exported, and the way to do encoding and decoding of specific types is now via theInterface.encodeType
andInterface.decodeType
methods:Interface.findTypeById
has been removedPreviously, you could get a type from the ABI via the
Interface.findTypeById
. This method was removed after introducing the new abi specification because the concept of a type has been split into concrete and metadata types. If you want a specific type, you can get it directly from the ABI.JsonAbiArgument
is no longer exportedThe
JsonAbiArgument
type isn't part of the new ABI spec (#596, #599) as such so we stopped exporting it. Its closest equivalent now would be a concrete type because it fully defines a type.Checklist
tests
to prove my changesdocs