Vec and heap type support

[adlerjohn]

Description

Currently, the SDK only supports static-sized arrays in the format [T; n] where T is the type and n is the length.

Soon, Sway will release Vec, a growable/mutable/dynamic vector. We need to support this on the SDK side.

Blockers

• stdlib Vec sway#1118: Full Vec support in Sway
• Introduce a .retd() method (or similar) that returns the content of a vector to be returned from a contract method sway#1994: An output-related work that needs to be done in the compiler, i.e., converting the heap data into stack data and returning it in a retd
• Emit type arguments for generic structs/enums in the JSON ABI file and update the function selector to include those type arguments sway#1993: Additional type-related data in the JSON ABI needs to be outputted by the compiler (the T in Vec<T> needs to be resolved and present in the ABI)
• Generalize the handling of generics in JSON ABI sway#2386
• refactor: fn_selector to be resolved during runtime via ParamTypes #587
• Special-case Vec when returning from a script sway#2900
• Support raw_ptr in abigen! #600

Design

Vec is implemented in Sway with a struct like this:

struct RawVec<T> {
    ptr: u64,
    cap: u64,
}

pub struct Vec<T> {
    buf: RawVec<T>,
    len: u64,
}

Once a Sway user imports it into their contract, Vec<T> and RawVec<T> will be exposed in the JSON ABI as regular structs. This will be abigen!'d on the SDK side, turning these two Sway structs into equivalent Rust structs.

Passing data in and out using Vec will be the most challenging part.

Passing in a Vec<T> to a contract call in Rust-land means we have to encode the length len, the pointer ptr, and the capacity cap. But where is the ptr pointing to? It will point to where the data lives inside the script_data, where we'll have to encode the actual content of the Vec<T>. This should suffice and, in Sway-land, a user should be able to access the contents of the Vec<T> param in their contract method.

Taking the returned data, in Rust-land, from a contract call that returns a Vec<T> means this, which should be simpler than the encoding part.

Once the SDK is unblocked by the compiler, the SDK needs to encode the vector data into script_data and point to it using the Vec's ptr.

Update August 16th, 2022

We've decided to support only Vec as inputs for now. Once that's done, Vec as output will be effectively a log of its data in the Receipts.

[digorithm]

Reopening to use this as a tracker for the vec output support (#602).

[iqdecay]

Support for Vec was added in #848, support for bytes was added in #868.
Support for those types as script returns will be tracked in #866.