Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IDL doesn't support PhantomData #3241

Open
cryptopapi997 opened this issue Sep 11, 2024 · 3 comments
Open

IDL doesn't support PhantomData #3241

cryptopapi997 opened this issue Sep 11, 2024 · 3 comments
Labels
feature idl related to the IDL, either program or client side

Comments

@cryptopapi997
Copy link
Contributor

cryptopapi997 commented Sep 11, 2024

If we define an account like so

use std::marker::PhantomData;

use anchor_lang::prelude::*;

declare_id!("B8v9C4JA5CqMWcoKYfA2hQSEytFxPVk1iWeEjXQxCvS3");

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

    pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
        msg!("Greetings from: {:?}", ctx.program_id);
        Ok(())
    }
}

#[derive(Accounts)]
pub struct Initialize<'info> {
    pub data_obj_acc: Account<'info, MyAcc<MyStruct>>,
}

#[account]
pub struct MyAcc<T> {
    _p: PhantomData<T>,
}

#[derive(AnchorDeserialize, AnchorSerialize, Clone)]
pub struct MyStruct {}

it compiles fine if we compile with anchor build --no-idl. If we try to build the idl however, we get a bunch of errors (I'm guessing because the idl tries to include PhantomData in the idl itself but it isn't serializable). I'm not sure if this is intentional or not, but if it isn't it would be nice to support PhantomData.

@acheroncrypto acheroncrypto added idl related to the IDL, either program or client side feature labels Sep 12, 2024
@acheroncrypto
Copy link
Collaborator

IDL only supports a small subset of types:

anchor/idl/spec/src/lib.rs

Lines 282 to 310 in 340e9c1

pub enum IdlType {
Bool,
U8,
I8,
U16,
I16,
U32,
I32,
F32,
U64,
I64,
F64,
U128,
I128,
U256,
I256,
Bytes,
String,
Pubkey,
Option(Box<IdlType>),
Vec(Box<IdlType>),
Array(Box<IdlType>, IdlArrayLen),
Defined {
name: String,
#[serde(default, skip_serializing_if = "is_default")]
generics: Vec<IdlGenericArg>,
},
Generic(String),
}

All these types are more or less language-agnostic, but PhantomData is not. Additionally, there is pretty much nothing useful a client can do with this information.

The best we can do is to skip PhantomData fields during the IDL generation.

@cryptopapi997
Copy link
Contributor Author

If skipping PhantomData during idl generation is a valid option for you, happy to open a PR for this. Although I believe this will cause issues with the generic argument, as you mentioned in #3148 that the anchor idl never officially supported generics.

What do you suggest is the best approach here?

@acheroncrypto
Copy link
Collaborator

I think skipping is the better option at least for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature idl related to the IDL, either program or client side
Projects
None yet
Development

No branches or pull requests

2 participants