lang: Fix account try_from usage

[acheroncrypto]

Problem

Using try_from in the instruction handler:

pub fn try_from(ctx: Context<TryFrom>) -> Result<()> {
    Account::<MyAccount>::try_from(&ctx.accounts.my_account)?;
    Ok(())
}

results in:

error: lifetime may not live long enough
  --> programs/try-from/src/lib.rs:15:9
   |
14 |     pub fn try_from(ctx: Context<TryFrom>) -> Result<()> {
   |                     ---
   |                     |
   |                     has type `anchor_lang::context::Context<'_, '1, '_, '_, TryFrom<'_>>`
   |                     has type `anchor_lang::context::Context<'_, '_, '_, '_, TryFrom<'2>>`
15 |         Account::<MyAccount>::try_from(&ctx.accounts.my_account)?;
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ argument requires that `'1` must outlive `'2`

Details

Ideally, the fix would be limited to Anchor internals without needing a breaking change to the users. However, this is difficult to achieve because #2656 added the same lifetime requirement for the AccountInfo references:

anchor/lang/src/accounts/account.rs

Lines 226 to 229 in c93b33a

	pub struct Account<'info, T: AccountSerialize + AccountDeserialize + Clone> {
	account: T,
	info: &'info AccountInfo<'info>,
	}

The info: &'info AccountInfo<'info> part is incompatible with Anchor's codegen because accounts passed to the context has a shorter lifetime than the AccountInfo's internal lifetime. While the lifetime annotations are incorrect based on Anchor's codegen, it's also not accidental. To properly annotate these lifetimes, we'd have to add another lifetime to the Account type(and all other account types) which would significantly hinder the developer experience since it's a public API.

In short, this problem is caused by annoting the same lifetimes in places where it's technically incorrect but we're doing so in order to not have multiple lifetimes in account types.

One possible solution for this problem is to elide the lifetimes by using core::mem::transmute. Using transmute is heavily discouraged but my understanding is, this should be safe to do in this case because both accounts lifetime and the AccountInfo's internal lifetime live longer than the user's instruction handler.

Usage

try_from!(Account::<MyAccount>, ctx.accounts.my_account)

Summary of changes

• Add a test program for try_from usage
• Add try_from! macro

[vercel]

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

A member of the Team first needs to authorize it.

[juchiast]

it is not correct to transmute AccountInfo<'a> into a shorter lifetime because it contains Rc<RefCell<&'a mut>>, making it invariant, the issue is explained in https://doc.rust-lang.org/nomicon/subtyping.html#variance . Basically, somewhere else in the code might still hold the reference to longer lifetime 'a, when you transmute it to a shorter lifetime 'b and write to it, you make a use-after-free bug.

I wonder why use RefCell holding a mutable reference at all? I did not dig into anchor code yet so I don't know why it is needed.

[acheroncrypto]

it is not correct to transmute AccountInfo<'a> into a shorter lifetime because it contains Rc<RefCell<&'a mut>>, making it invariant, the issue is explained in https://doc.rust-lang.org/nomicon/subtyping.html#variance . Basically, somewhere else in the code might still hold the reference to longer lifetime 'a, when you transmute it to a shorter lifetime 'b and write to it, you make a use-after-free bug.

Generally speaking, what you said is correct, but I don't think it applies here because the main reason for using this macro is to first declare an account as an UncheckedAccount, then convert it to a checked type, e.g. Account. When you do this, you're declaring you'll let Anchor handle the serialization of the data to the account (in the exit routine), meaning it would be incorrect to write to the raw account data yourself independent of the "use-after-free" bug you mentioned.

That being said, this PR is stale and won't get merged. #3340 helps this specific issue too, but it still requires declaring the lifetimes of the accounts struct and the context are the same (e.g. Context<'info, MyIx<'info>>). We can improve this further by handling the annotations automatically during macro generation.

I wonder why use RefCell holding a mutable reference at all? I did not dig into anchor code yet so I don't know why it is needed.

That part is not coming from Anchor code, as AccountInfo is defined in solana-program. I think mistakes were made in the initial days though, that type doesn't make much sense.

[acheroncrypto]

Superseded by #3340