lang: Add ProgramData account #1095
Conversation
| } | ||
| // Easy to implement. Just need to write a test. | ||
| // Feel free to open a PR. | ||
| assert!(!state.is_zero_copy, "Trait implementations not yet implemented for zero copy state structs. Please file an issue."); |
There was a problem hiding this comment.
clippy asked for this
| @@ -0,0 +1 @@ | |||
| [114,99,192,17,48,208,90,184,231,46,220,91,47,115,132,253,218,163,228,101,8,121,220,138,41,140,176,127,254,91,51,28,176,244,174,182,223,57,57,125,117,201,31,213,9,39,207,212,100,173,88,252,61,235,89,156,53,86,4,90,16,251,191,219] | |||
There was a problem hiding this comment.
this exists so it can be copied into the target/deploy folder. see the github actions job test-program-data
lang/src/program_data.rs
Outdated
| } | ||
|
|
||
| #[derive(Debug, Clone)] | ||
| pub struct ProgramData<'info> { |
There was a problem hiding this comment.
What do you think about making a wrapper type for UpgradeableLoaderState that implements the required traits? Then we could use Account<UpgradeableLoaderState> vs ProgramData.
There was a problem hiding this comment.
sg,Ill try.
although I'd prefer to have an Account<ProgramData> and an Account<Program> instead of Account<UpgradeableLoaderState>. or all three of them. cause the first two are useful for constraints. You can't match easily on an enum.
There was a problem hiding this comment.
hmm actually idk if Account<Program> is a good idea. We already have Program<'info, PROGRAM> which also checks that we have the correct program. We could just add the data of the program (=programdata_address) to that struct as an option. It would be Some(..) if the given program is owned by the upgradable loader.
Account<ProgramData> and Account<UpgradableLoaderState> still sg to me tho
There was a problem hiding this comment.
I've added ProgramData and UgpradableLoaderState and they work, just gotta decide what to do with Program
There was a problem hiding this comment.
Let's add Option<Pubkey> to Program<'info, T> for the programdata_address. I'm not a fan of Account<Program> since there are no address checks done.
There was a problem hiding this comment.
yup, agree.
can merge this pr and do that in a separate issue tho. theyre not connected.
There was a problem hiding this comment.
already created it some days ago #1094
paul-schaaf
force-pushed
the
lang__add_programdata_account
branch
from
504ed1f
to
67dc5cf
Compare
tests/program-data/.gitignore
Outdated
| @@ -0,0 +1,5 @@ | |||
| .anchor | |||
There was a problem hiding this comment.
I removed it but added it back so it can gitignore yarn.lock in the test repo.
|
|
||
| declare_id!("Cum9tTyj5HwcEiAmhgaS7Bbj4UczCwsucrCkxRECzM4e"); | ||
|
|
||
| // TODO: Once anchor can deserialize program data, update this test. |
There was a problem hiding this comment.
Is this comment still relevant?
There was a problem hiding this comment.
yes, we should have a test that checks that you can uses settings, program, program_data, and the upgrade authority together to set data. this use case was what got these issues created.
eventually we should have a test that can check the following
#[derive(Accounts)]
#[instruction(admin_data: u64)]
pub struct SetAdmin {
upgrade_authority_address: Signer<'info>,
#[account(has_one = programdata_address)
program: Program<'info, <YOUR_PROGRAM>,
#[account(has_opt = upgrade_authority_address)]
programdata_address: ProgramData<'info>
}
(pending has_opt feature approval)
There was a problem hiding this comment.
program data in that comment was referring to the data of the Program (i.e. programdata_address), not the data of ProgramData.
closes #1083