Add serde feature - token-2022

[omertxyz]

We would like to serialize TokenInstruction to json in order to have easier indexing, already implemented it for Metaplex token. This is still a draft I worked on with Lawrence Wu.

• Add ser/deser traits to structs that are used when serde TokenInstruction
• Use serde_as package to serialize Pubkey as string rather than bytes
• Since COption doesn't implement serde, add manual serde
• Tested roundtrip with some and none values

cc: @joncinque @CriesofCarrots @lwus

[mvines]

How about adding this to token-2022 instead, which should already be a superset of token

[omertxyz]

@mvines thanks for the response, I'm not super familiar with token-2022, is that just the new version of token? As long as we can use it for indexing existing contracts that's fine on my side.

[mvines]

It's the next iteration of the token program, source is at https://github.com/solana-labs/solana-program-library/tree/master/token/program-2022

From a client perspective, using the spl-token-2022 should be equivalent to using the spl-token crate as long as you don't opt in to the new token 2022 features. My request has three motivations:

1. Sneakily push users to start looking at token 2022 to drive interest/adoption
2. We'd be more willing to land new features into token 2022, like this PR, because that code is under active development
3. Anything that goes into the stable token crate also should go into token 2022, so you'd be asked to make these changes in token 2022 regardless!

[omertxyz]

@mvines moved it to token-2022 as requested

[mvines]

It'd be nice to add a step in CI to run the new serde-feature tests in this PR, somewhere in here: https://github.com/solana-labs/solana-program-library/blob/master/.github/workflows/pull-request-token.yml#L16

[omertxyz]

@mvines @lwus can you help me with the CI thing? I'm not familiar with github syntax

[jnwng]

i might be mistaken, but the existing directive to "Build and test token" also recurses into the token/program-2022 folder to run tests there:

including the folder that the serialization.rs file is located in:

source

while i can't verify that the tests included in this PR will run successfully until the PR gets approved, just wanted to be sure we didn't miss anything—@mvines is there a different configuration you're expecting for this serialization test in particular that you want to be sure we run in CI?

[mvines]

@mvines is there a different configuration you're expecting for this serialization test in particular that you want to be sure we run in CI?

yeah, pretty sure these new tests wont be run by default because they're under the new "serde" feature, so we need a new step like I mentioned here: #3291 (comment)

[jnwng]

@joncinque this looks suspicious—i had expected the serde-feature = ["serde", "serde_with"] in Cargo.toml to handle enabling this optional dependency, but cargo kept complaining to me whenever i omitted this feature. i have this here to make sure CI passes right now, but if you have some insight here that'd be useful!

[joncinque]

I made a couple of little changes to get this to work on CI 🤞 , and some little cosmetic changes to make things clearer.

Unfortunately, we can't use the same feature name as a crate until we start using Rust 1.60, so I went with the name serde-traits, which seemed nice enough and didn't conflict with other crate names. We can update it to serde with 1.11 if the BPF compiler supports it, not sure what version it's on. https://doc.rust-lang.org/cargo/reference/features.html#optional-dependencies for more info

Also, there was an annoying deprecation warning because of rust-lang/rust#87454, so I just did #![allow(deprecated)] in the file, which was the only option unfortunately.

[joncinque]

By the way, what do you think about implementing serde on all instructions the same way? It looks like only the mint initialization instructions are using the coption_serde for COption parameters.

[jnwng]

By the way, what do you think about implementing serde on all instructions the same way? It looks like only the mint initialization instructions are using the coption_serde for COption parameters.

i think this makes sense! we had targeted just the instructions we were concerned with but shouldn't be a huge lift. looks like we probably only need to serialize the pubkeys; should this extend to all the extension instruction structs too? tactically, is there a way to validate this more efficiently or should we enumerate through all those instructions in the test to validate the serialization annotations?

[joncinque]

Yep that was my thought! We don't have to do it in this PR though. If you create an issue outlining the rest of the work, then we can merge this one 😄

[joncinque]

I rebased, so this should be good to go on my side once it passes CI

[jnwng]

I rebased, so this should be good to go on my side once it passes CI

ready to go! outlined some of the information i know about in #3325