lang: Remove 3 lifetime definitions from Context

[acheroncrypto]

Problem

Context struct definition includes 4 lifetimes:

anchor/lang/src/context.rs

Line 24 in ebbad72

pub struct Context<'a, 'b, 'c, 'info, T: Bumps> {

While this is technically correct, and it's also what Rust does by default, it results in a poor developer experience because the lifetimes leak to the Anchor users in various cases. For example, remaining accounts usage requires annotating the instruction handler with lifetimes, which is quite difficult to figure out for people who're less experienced with lifetimes (not to mention this is completely unnecessary).

Summary of changes

Remove 3 (out of 4) lifetimes from the Context struct. In other words, make all references have the same lifetime. This makes it so much easier for Anchor users to to handle places that Context is used. For example, remaining accounts usage:

anchor/tests/misc/programs/remaining-accounts/src/lib.rs

Lines 25 to 27 in ebbad72

	pub fn test_remaining_accounts<'c: 'info, 'info>(
	ctx: Context<'_, '_, 'c, 'info, TestRemainingAccounts>,
	) -> Result<()> {

simply becomes:

pub fn test_remaining_accounts(ctx: Context<TestRemainingAccounts>) -> Result<()> {

[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]

How does this interact with the issues in #2770 and #3341
Basically, the type &'info AccountInfo<'info> is not very usable, AccountInfo<'info> is invariant because it contains RefCell, meaning we cannot cast the lifetime AccountInfo<'info> into a struct with shorter lifetime AccountInfo<'a>.

[acheroncrypto]

How does this interact with the issues in #2770 and #3341

It basically fixes the problem. It still requires a lifetime annotation, but we should be able to handle this automically in the program macro.

Basically, the type &'info AccountInfo<'info> is not very usable

Yeah, but the alternative is worse (declaring another lifetime as explained in the "Details" section of #2770).

AccountInfo<'info> is invariant because it contains RefCell, meaning we cannot cast the lifetime AccountInfo<'info> into a struct with shorter lifetime AccountInfo<'a>.

Does that even matter here? I don't think the Rust compiler would allow you to overwrite the data with a reference declared inside the instruction handler.

[juchiast]

Does that even matter here? I don't think the Rust compiler would allow you to overwrite the data with a reference declared inside the instruction handler.

With a normal struct, it is possible to change the lifetime to a smaller one by re-borrowing

struct X<'a> {
    s: &'a str,
}

fn cast<'a, 'b>(x: X<'a>) -> X<'b> where 'a: 'b {
    X { s: &*x.s }
   // or just `return x;`, rust can cast automatically
}

but we can't do this with AccountInfo<'a>. It's impossible to make &'a AccountInfo<'a> reference, if you need to use &'a AccountInfo<'a> reference, you are stuck with that lifetime forever.

spl-candy-guard case: they use UncheckedAccount<'info>, do some check manually then call Account::try_from. Fortunately we can still recover the original &'info AccountInfo<'info> inside UncheckedAccount, if the lifetime is lost (by cloning, for example), it is impossible to create &'info AccountInfo<'info> again.

[acheroncrypto]

Does that even matter here? I don't think the Rust compiler would allow you to overwrite the data with a reference declared inside the instruction handler.

With a normal struct, it is possible to change the lifetime to a smaller one by re-borrowing

struct X<'a> {
    s: &'a str,
}

fn cast<'a, 'b>(x: X<'a>) -> X<'b> where 'a: 'b {
    X { s: &*x.s }
   // or just `return x;`, rust can cast automatically
}

but we can't do this with AccountInfo<'a>. It's impossible to make &'a AccountInfo<'a> reference, if you need to use &'a AccountInfo<'a> reference, you are stuck with that lifetime forever.

Yeah, I'm aware of that, but I'm not sure how that answers my initial comment about the Rust compiler not allowing you to overwrite the data with a reference declared inside the instruction handler.

spl-candy-guard case: they use UncheckedAccount<'info>, do some check manually then call Account::try_from. Fortunately we can still recover the original &'info AccountInfo<'info> inside UncheckedAccount, if the lifetime is lost (by cloning, for example), it is impossible to create &'info AccountInfo<'info> again.

Since you're using "they" when referring to the Metaplex team, I'm assuming you're not from the Metaplex team, and you just want to interact with the mpl-candy-guard program. I'm also assuming you're using Anchor v0.29 and Solana v1.18, since that's what you used in metaplex-foundation/mpl-candy-machine#76.

If my assumptions are correct, then trying to fully upgrade that program is completely unnecessary for your use case, because you don't need the program's internal logic to be able to interact with a program (you only need implementation signatures). If you want to use the program's crate as a CPI client or an off-chain client, you can safely remove all its instruction handler logic, including the parts where it uses Account::try_from.

As a side note, the mpl-candy-guard's usage of Account::try_from in order to implement some sort of an optional account check also seems redundant in newer Anchor versions because Anchor now supports optional accounts in accounts structs with Option<T>.

Furthermore, you don't even need to upgrade anything to interact with older programs if you're using the latest version (v0.30.1). In fact, you don't even need to add programs as a dependency. Here are some useful links:

• https://www.anchor-lang.com/release-notes/0.30.0#dependency-free-program-declaration
• https://docs.rs/anchor-lang/0.30.1/anchor_lang/macro.declare_program.html
• lang: Add declare_program! macro #2857
• https://en.wikipedia.org/wiki/XY_problem