lang: associated_token constraints don't work when setting token_program

[wjthieme]

supersedes and resolves #2541

When setting associated_token constraints using a specified token_program other than the standard token program. A constraint fails because it relies on a hardcoded version of token_program instead of the user-specified one. This makes it impossible to use associated_token constraints that use the Token2022 token program.

This PR fixes the check by using get_associated_token_address_with_program_id instead of get_associated_token_address which it was using previously.

This PR also adds a new test program that uses the associated_token constraints both with and without specifying a token_program. This test would throw an AccountNotAssociatedTokenAccount before the changes introduced in this PR.

tl;dr: This PR fixes a bug that makes using a custom token_program impossible with the associated_token constraints.

[vercel]

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

A member of the Team first needs to authorize it.

[acheroncrypto]

Yes, please check #2541 (comment).

This line also needs to change.

anchor/lang/syn/src/codegen/accounts/constraints.rs

Line 945 in 6eacad4

let __associated_token_address = ::anchor_spl::associated_token::get_associated_token_address(&wallet_address, &#spl_token_mint_address.key());

And a test case for this would be great #2447 (comment).

[wjthieme]

Done!

[acheroncrypto]

Done!

Hey, thank you so much for adding the tests but could you move them to misc tests where the other similar token related tests are located? #2447 (comment)

[wjthieme]

Thanks @acheroncrypto! Must have overlooked those. I changed the already existing tests for associated token constraints that were supposed to catch this bug as I felt adding a new cases would be a little bit redundant

[acheroncrypto]

I changed the already existing tests for associated token constraints that were supposed to catch this bug as I felt adding a new cases would be a little bit redundant

Those tests don't use the interface program so tests will fail with the current form. It would be better to add a new test case for this situation because we would also want to keep the tests for the standard token program.

[wjthieme]

tests will fail with the current form

Interesting as the tests were succeeding when I ran them locally. Let me investigate

[acheroncrypto]

tests will fail with the current form

Interesting as the tests were succeeding when I ran them locally. Let me investigate

It succeeds because there is no functional change in tests(token program id is the same) but it will fail if you put the correct Token 2022 program id.

[wjthieme]

It succeeds because there is no functional change in tests(token program id is the same) but it will fail if you put the correct Token 2022 program id.

Yep. Figured that out. I fixed the tests that uses a custom token_program by using InterfaceAccounts which is needed because otherwise it Anchor checks the owner to TOKEN_PROGRAM_ID instead of the custom one you specify. ie. using Account<Mint> and Account<TokenAccount> do not work for custom token_program since Account checks ownership to the spl_token::id().

There are a couple of functions in @solana/spl-token that do not work for Token2022 tokens (even though we are specifying the Token2022 program id). I suspect that the outdated version of @solana/spl-token expects a certain account size but Token2022 mint and token accounts are larger. Functions in question:

• Token.getAccountInfo
• Token.getMintInfo

All tests should be passing now at least. @acheroncrypto lemme know what you think

[acheroncrypto]

It succeeds because there is no functional change in tests(token program id is the same) but it will fail if you put the correct Token 2022 program id.

Yep. Figured that out. I fixed the tests that uses a custom token_program by using InterfaceAccounts which is needed because otherwise it Anchor checks the owner to TOKEN_PROGRAM_ID instead of the custom one you specify. ie. using Account<Mint> and Account<TokenAccount> do not work for custom token_program since Account checks ownership to the spl_token::id().

I'd still prefer not modifying existing program instructions since they are testing a different case(where you use Account instead of Interface) but current changes should be fine too.

There are a couple of functions in @solana/spl-token that do not work for Token2022 tokens (even though we are specifying the Token2022 program id). I suspect that the outdated version of @solana/spl-token expects a certain account size but Token2022 mint and token accounts are larger. Functions in question:

• Token.getAccountInfo
• Token.getMintInfo

Token 2022 is a superset of the standard Token program which means anything that works with Token should also work with Token 2022. Mint size is 82 for both Token and Token 2022 and Account size is 165 for both Token and Token 2022.

All tests should be passing now at least. @acheroncrypto lemme know what you think

They don't pass because BN is not defined. You can use anchor.BN instead.

[wjthieme]

Token 2022 is a superset of the standard Token program which means anything that works with Token should also work with Token 2022. Mint size is 82 for both Token and Token 2022 and Account size is 165 for both Token and Token 2022.

Yep, but getting Error: Invalid account size when using Token.getAccountInfo / Token.getMintInfo which is not happening when using AccountLayout.decode / MintLayout.decode. Token2022 mints and account sizes should be dynamic based on which extensions are included IIRC.

They don't pass because BN is not defined. You can use anchor.BN instead.

Fixed

[acheroncrypto]

associated_token::token_program will still fail with Token 2022 on non-init accounts. I've modified this test to use Token 2022 to show the failure(#2603 (comment)).

[wjthieme]

Think this one is done now, right? Thanks for fixing that last issue @acheroncrypto!

[acheroncrypto]

Thank you!