Additional anchor types

[Ikrk]

Added support for all Anchor types. Now, any context structure supported by Anchor 0.29.0 should be correctly parsed and the appropriate snapshot structs generated correctly.

Before this change, the parsing was done "manually". Now however we are using the parser directly from Anchor that has been exposed in Anchor 0.29.0 when using the idl-build feature flag. The types Interface and InterfaceAccount were not tested.

Also, this PR changes the way how the snapshot accounts are constructed. Now only the explicitly optional accounts and the accounts that have the init or close constraints are wrapped into the Option type. That make the work with accounts within the check methods easier because it is not necessary to always verify if there is Some account.

Finally, this PR modularized the implementation within the snapshot_generator.rs file to make it more readable.

[Ikrk]

The accounts snapshots code generation was changed and the tests do not pass anymore. I will correct it next week.

[lukacan]

When used on fuzz_example3, the freshly generated account_snapshots.rs contains an error for "escrow_pda_authority". The account is expected to be:

• pub escrow_pda_authority: AccountInfo<'info>, // inside WithdrawUnlockedSnapshot

However, the code is generated as: let escrow_pda_authority = accounts_iter .next() .ok_or(FuzzingError::NotEnoughAccounts)?;

where escrow_pdaauthority has type Option<AccountInfo<'>>

[lukacan]

I made some additional testing today and so far I found another issues:

• Boxed accounts are not correctly generated, field within the XYSnapshot struct expects:
  • Box<Account<'info, T>>,
  • However, boxed account within deserialize_option is of type T (not Boxed)
• If we use PDA accounts for Data accounts, we can argue that it is in the user`s hands to define correct seeds within each get_accounts instruction for the PDA (Data Account)
  • However for regular keypair accounts, even though the FuzzAccounts structure is global, AccountIDs are local for every instruction -> two instructions -> two (often)different AccountIDs -> two different Accounts -> first account is initialized within the first instruction as data Account -> second account cannot be deserialized for the second instruction as it is a different account.

EDIT: I was further testing account types based on anchor_lang::accounts for Anchor 0.28.0, and my suggestions/observations:

• Account
  • If PDA, user uses get_or_create_account with seeds specified by them, so even AccountIDs are different across instructions, the user can specify correct seeds -> resulting in the correct PDA
  • If keypair, user can use constant AccountIDs (instead of the ones generated by fuzzer) across multiple instructions resulting in the same account returned from each get_or_create_account -> Initialized Account will correctly deserialize in subsequent deserialize_options functions (however I do not like the constants).
  • AccountInfo, we can maybe wrap this in Option\<>
  • AccountLoader, looks good
• for account read/write within the check function, it is needed to use load/load_mut
• AccountLoader::try_from checks for the account owner and discriminator, so same case as for the Account?
  • Boxed I would suggest to handle this as Account , without Boxing
• for Box\<InterfaceAccount\<T>> , handle it as InterfaceAccount\<T>
  • Interface, should be the same as Program
  • InterfaceAccount, should be the same as Account
  • Option\<T>, handle as Option\<T>
• we can have Option\<Box\<T>> , would handle as Option\<T>
  • Program, in the user`s hands
  • Signer, no problem here
  • SystemAccount, no problem
  • Sysvar, in user`s hands
  • UncheckedAccount, same as AccountInfo

[Ikrk]

Finally I have made following modifications:

• Boxed accounts are handled as normal accounts.
• Init and close constraints on accounts generate an optional Snapshot account.
  • this is because the same Snapshot struct is used for the snapshot before and after the instruction. In case of account with the Account type, it is not possible to deserialize the account before initialization or after close. Therefore the account will be set to None.
• In case of AccountInfo, UncheckedAccount and Signer, the user can pass uninitialized accounts to the program and the runtime will provide an empty account to the program. This behavior is simulated to avoid AccountNotFound errors.

[lukacan]

Good job ! I did some testing and it looks like everything generates correctly.