Solitaire parses accounts using two traits, FromAccounts and Peel. The
FromAccounts derive macro generates a function, `FromAccounts::from()`,
which calls `Peel::peel` to construct each field in the struct:
```
let example = Example {
foo: Peel::peel(next_account_iter(accs)?),
bar: Peel::peel(next_account_iter(accs)?),
baz: Peel::peel(next_account_iter(accs)?),
...,
}
```
The FromAccounts derivation also attempts to implement Peel for the
structure itself however, which means `Example` itself is embeddable as
a field in another accounts struct. This is only used in ClaimableVAA
which is a large source of confusion and the complexity is not worth
maintaining.
This commit removes the recursion by:
1) Removing the `impl Peel` derived by FromAccounts.
2) Removes the AccountInfo iterator from Context as it is no longer needed.
3) Adds the current parsed account to Context instead, safe thanks to (2)
4) Move message out of ClaimableVAA and pass in to verify everywhere instead.
5) Removes Peel/FromAccounts from ClaimableVAA.
The integration tests were previously just copied over from the
token-bridge directory and not changed at all (they still referenced the
token-bridge crate).
Clean up the files and add tests for basic functionality like sending
and receiving native + wrapped NFTs.
Merge all the separate solana crates into a single workspace. This is
the same thing we do for terra and will make it easier to check / lint /
test all the crates together.
The type of the `ix_data` binding withing the solitaire! macro expansion
is explicitly annotated with its type, which comes from the macro's
pattern binding `$kind`. However, this type annotation is entirely
optional, since `ix_data` is passed in as an argument to `$fn`, whose
type forecs `ix_data` anyway, and rust will happily infer that from the
application. So we remove the explicit annotation which makes the entry
point macro easier to use.
commit-id:d428306c
Chirantan Ekbote
Stan Drozd
Reisen
Csongor Kiss
Hendrik Hofstadt
Reisen
Evan Gray