lang: derive arbitrary traits for the instruction data

[skrrb]

implements Arbitrary trait for the anchor-generated instruction module when the program is compiled with the arbitrary feature (this requires the arbitrary crate).

This is particularly useful for fuzzing. For example:

use anchor_lang::prelude::*;

declare_id!("Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS");

#[program]
pub mod arbitrary_impl {
    use super::*;

    pub fn dummy_instruction(_ctx: Context<Dummy>, number: u8) -> Result<()> {
        let _ = number;
        Ok(())
    }
}

#[derive(Accounts)]
pub struct Dummy {}

#[cfg(all(test, feature = "arbitrary"))]
mod test {
    use super::*;
    use arbitrary::{Arbitrary, Unstructured};

    #[test]
    fn implements_arbitrary() {
        let mut u = Unstructured::new(&[1, 2, 3]);
        assert_eq!(u.len(), 3);

        let _ = instruction::DummyInstruction::arbitrary(&mut u);
        assert_eq!(u.len(), 2);
    }
}

[vercel]

@skrrb is attempting to deploy a commit to the coral-xyz Team on Vercel.

A member of the Team first needs to authorize it.

[skrrb]

synced with master. for reference, this is what openbook fuzz test currently use https://github.com/openbook-dex/openbook-v2/blob/8928d4cb23efe4864fc05aab9f00519eacf83720/programs/openbook-v2/fuzz/Cargo.toml#L28

[acheroncrypto]

Thanks for the PR. However, I think we should be able to support custom instruction attributes on the framework level with #2339, which I'm planning to get in for the next release. That specific PR currently doesn't support cfg_attr, but we should easily be able to add support for that too.

Overall, having generic support seems much better than hardcoding this feature in the codegen.

[skrrb]

Thanks for the PR. However, I think we should be able to support custom instruction attributes on the framework level with #2339, which I'm planning to get in for the next release. That specific PR currently doesn't support cfg_attr, but we should easily be able to add support for that too.

Overall, having generic support seems much better than hardcoding this feature in the codegen.

oh, i was not aware of that PR, will take a close look. However, a quick question i'm not really sure how to solve with this approach: how should be differentiated if the attributes need to be applied to the function itself, or only to the underlying #ix_name_camel struct (as in this case)?

[acheroncrypto]

Wouldn't applying cfg to both and cfg_attr to only the generated struct work for most cases? If not, we can also implement a custom syntax to decide where to apply the attributes.

[skrrb]

closed in favor of #2963