Generate Rust clients

[grod220]

After #236 (comment), think there is good reason to generate rust clients and use them within our tests. This will prevent the IDL from drifting from a spec that actually works in practice.

In #198, we decided against generating clients given the token program will perhaps be the only consumer of this IDL. That said, I think it's still helpful to generate these as 1) other consumers may want directly interact with this program using helpers without going through the token program and 2) the token program can easily import these and use them versus generating it in that repo.

This is a two parter: A) generate clients (this PR), B) integrate them into the tests. Think part B comes with some decent refactoring, so isolating that work to later.

[joncinque]

It lives in the end! https://crates.io/crates/spl-associated-token-account-client

We had the client crate earlier when we wanted to use the generated clients more, but then the interface crates were easier to work with whenever there were upstream changes, especially as they were used by agave.

Historically, partly due to my ignorance of how the renderers work, it was faster to just update the interface crate. If we make the tests use the generated clients, then we're forced into keeping the renderers up to date.

It's totally fine if you want to go with that approach, but it will likely take more work.

To save yourself a headache, I would recommend just testing that the generated client creates the same exact instructions as the interface.

[grod220]

I see, thanks for the context. I'd be happy to move it into the pinocchio/interface crate, but sadly the currently generate codama clients use the standard library. Investigating what it would take to make it no-std and will swing back.

[joncinque]

The pinocchio generators will be pretty different since it outputs no-std types, ie InstructionView instead of Instruction. @febo started that work, but I don't think it's ready yet.

Feel free to merge this if you want, but having the tests depend on the client crate may cause annoyance in the future, which is why I would just have tests in the client library to make sure that they generate the same instructions as the interface crate

[grod220]

Got this PR up codama-idl/renderers-rust#97 which will enable the generated rust client to be no-std friendly. After that is merged/published, we should be able to move that generated/ folder into the pinocchio-interface crate and let repo tests depend on that (removing the need for additional client crate).

tests in the client library to make sure that they generate the same instructions as the interface crate

Think if tests can use the same client code, we won't need redundant ix helpers + equivalence tests.

[joncinque]

Sorry, I should have been clearer. The pinocchio interface shouldn't use types that require allocations, ie it should use InstructionView instead of Instruction. The pinocchio interface is meant to be used on-chain, while the other types (like Instruction) are better suited for off-chain.

For that reason, it would be better to remake the -client crate if we want to generate these.

I'm not a huge fan of the additional dependencies required by the generated crates at the moment, mostly borsh, but if they really help, go for it!

[grod220]

Talked offline on this. Pinocchio crates should be no-std + no alloc and the currently generated clients don't get us quite there yet. Tests using idl-generated-clients isn't an urgent need, so we can continue using interface ix helpers until InstructionViews are available.