fix: SystemAccount compilation error in #[derive(Accounts)] macro (#3696) #3752

hasip-timurtas · 2025-06-20T11:57:46Z

Problem

Using SystemAccount<'info> as a field in a struct with #[derive(Accounts)] was causing compilation errors:

error[E0425]: cannot find crate `try_from_unchecked` in the list of imported crates
error[E0425]: cannot find crate `try_from` in the list of imported crates

Reproduction case:

#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(init, payer = user, space = 0)]
    pub system_account: SystemAccount<'info>,  // ❌ This failed to compile
    #[account(mut, signer)]
    pub user: Signer<'info>,
    pub system_program: Program<'info, System>,
}

Root Cause

The issue occurred in lang/syn/src/lib.rs in the from_account_info method:

SystemAccount and Signer have try_from methods that take only one parameter (AccountInfo)
However, they were falling through to the default _ case which generates code for two parameters
The default case generates: #container_ty::try_from(#owner_addr, &#field)
For SystemAccount, container_ty() returns quote! {} (empty), making this: ::try_from(owner_addr, &field) ❌
But SystemAccount::try_from only accepts: try_from(info: &AccountInfo) ✅

Solution

Added specific cases for SystemAccount and Signer in the from_account_info method to generate the correct single-parameter try_from calls:

Ty::SystemAccount => {
    quote! {
        match SystemAccount::try_from(&#field) {
            Ok(val) => val,
            Err(e) => return Err(e.with_account_name(#field_str))
        }
    }
}
Ty::Signer => {
    quote! {
        match Signer::try_from(&#field) {
            Ok(val) => val,
            Err(e) => return Err(e.with_account_name(#field_str))
        }
    }
}

Testing

✅ Compilation Tests:

cargo build --workspace --exclude anchor-cli - SUCCESS
tests/system-accounts program builds (has existing SystemAccount usage)
tests/misc program builds (added test case)

✅ Validation:

The existing tests/system-accounts/programs/system-accounts/src/lib.rs already contains the exact failing pattern and now compiles successfully
No regressions: all other account types (Account, AccountLoader, UncheckedAccount, etc.) continue to work as before

✅ CI Integration:

SystemAccount tests are already part of the CI pipeline via tests/system-accounts

Files Changed

lang/syn/src/lib.rs - Core fix: Added specific cases for SystemAccount and Signer
tests/misc/programs/misc/src/context.rs - Added test case for SystemAccount
tests/misc/programs/misc/src/lib.rs - Added test handler

Backward Compatibility

✅ Fully backward compatible - no existing code needs to change. This only fixes previously broken SystemAccount usage.

Closes #3696

This commit introduces handling for `Signer` and `SystemAccount` types in the `Field` implementation, allowing for proper conversion and error handling. Additionally, a new `TestSystemAccount` struct is added to the test suite to facilitate testing of the `SystemAccount` functionality.

vercel · 2025-06-20T11:57:49Z

@hasip-timurtas is attempting to deploy a commit to the Solana Foundation Team on Vercel.

A member of the Team first needs to authorize it.

Aursen · 2025-07-01T16:43:27Z

Actually this is not a good thing to allow that:

    #[account(init, payer = user, space = 0)]
    pub system_account: SystemAccount<'info>,

Normally, you initialize the account to assign it to the current program. So, what’s the purpose of assigning it to a System Account in the context after the init?

hasip-timurtas · 2025-07-01T17:27:22Z

@Aursen Yes, you're right that this looks weird. I was just fixing the compilation error where SystemAccount and Signer types weren't handled in the field processing code.

The #[account(init, payer = user, space = 0)] with SystemAccount pattern is definitely edge case stuff. Most people should just use:

#[account(init, payer = user, space = 8 + MyData::INIT_SPACE)]
pub my_data: Account<'info, MyData>,

for their program data, or plain:

pub system_account: SystemAccount<'info>,

for existing system accounts.

But sometimes you actually need to create a system account at a deterministic PDA address, like when you're building something that other programs need to find later. It's rare but when you need it, the framework shouldn't just break.

I'm not trying to encourage this pattern or anything, just making sure the framework doesn't crash when people use it. If you think we should add a warning or better docs about when this makes sense vs the normal patterns, I'm down for that.

What do you think? Should we add some guardrails or is fixing the compilation issue enough for now?

hasip-timurtas mentioned this pull request Jun 20, 2025

#[derive(Accounts)] breaks on a struct with SystemAccount as a field #3696

Open

Aursen added lang Patch Change that can be done in a patch release labels Jul 1, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix: SystemAccount compilation error in #[derive(Accounts)] macro (#3696) #3752

fix: SystemAccount compilation error in #[derive(Accounts)] macro (#3696) #3752

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

fix: SystemAccount compilation error in #[derive(Accounts)] macro (#3696) #3752

Are you sure you want to change the base?

fix: SystemAccount compilation error in #[derive(Accounts)] macro (#3696) #3752

Conversation

Problem

Root Cause

Solution

Testing

Files Changed

Backward Compatibility

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!