chore: sync

Author: jktrn-osec

docs-v2/src/content/docs/basics/cpi.mdx

@@ -48,14 +48,14 @@ A CPI is constructed the same way as any other Solana instruction. The caller mu
 
 The System Program's `transfer(){:rs}` instruction requires a `from{:rs}` account that sends the SOL and a `to{:rs}` account that receives it. The `SolTransfer{:rs}` struct declares both accounts plus the System Program itself, since the CPI invokes that program:
 
-<Code code={lib} lang="rust" title="lib.rs" meta="{27-34} collapse={1-25}" />
+<Code code={lib} lang="rust" title="lib.rs" meta="collapse={1-26}" />
 
 The tabs below present three approaches to implementing the same CPI, each at a different level of abstraction:
 
 <Tabs groupId="language" items={['CpiContext{:rs}', 'invoke(){:rs}', 'Manual']}>
 <Tab>
 
-The first approach uses Anchor's [`CpiContext`](https://docs.rs/anchor-lang/latest/anchor_lang/context/struct.CpiContext.html), which bundles the `program_id{:rs}` and accounts required by the instruction. The `cpi_context{:rs}` is then passed to the `transfer(){:rs}` helper to invoke the instruction:
+The first approach uses Anchor's [`CpiContext{:rs}`](https://docs.rs/anchor-lang/latest/anchor_lang/context/struct.CpiContext.html), which bundles the `program_id{:rs}` and accounts required by the instruction. The `cpi_context{:rs}` is then passed to the `transfer(){:rs}` helper to invoke the instruction:
 
 <Code code={lib} lang="rust" title="lib.rs" meta="{15-22} collapse={1-9, 24-34}" />
 
@@ -201,7 +201,7 @@ The tabs below present two approaches to implementing the same PDA-signed CPI:
 <Tabs groupId="language" items={['CpiContext{:rs}', 'invoke_signed(){:rs}']}>
 <Tab>
 
-The first approach uses [`CpiContext`](https://docs.rs/anchor-lang/latest/anchor_lang/context/struct.CpiContext.html), then attaches the signer seeds via `with_signer(){:rs}`:
+The first approach uses [`CpiContext{:rs}`](https://docs.rs/anchor-lang/latest/anchor_lang/context/struct.CpiContext.html), then attaches the signer seeds via `with_signer(){:rs}`:
 
 <Code code={libPda} lang="rust" title="lib.rs" meta="{15-17,26,28} collapse={1-9, 30-44}" />
 
@@ -213,31 +213,3 @@ When the CPI executes, the Solana runtime validates that the supplied seeds and
 <Tab>
 
 The first approach is a wrapper around `invoke_signed(){:rs}` paired with `system_instruction::transfer(){:rs}`. Calling `invoke_signed(){:rs}` directly produces an equivalent CPI:
-
-```rust showLineNumbers=false {11,16}
-use anchor_lang::solana_program::{program::invoke_signed, system_instruction};
-
-pub fn sol_transfer(ctx: Context<SolTransfer>, amount: u64) -> Result<()> {
-    let from_pubkey = ctx.accounts.pda_account.to_account_info();
-    let to_pubkey = ctx.accounts.recipient.to_account_info();
-    let program_id = ctx.accounts.system_program.to_account_info();
-
-    let seed = to_pubkey.key();
-    let bump_seed = ctx.bumps.pda_account;
-
-    let signer_seeds: &[&[&[u8]]] = &[&[b"pda", seed.as_ref(), &[bump_seed]]];
-
-    let instruction =
-        &system_instruction::transfer(&from_pubkey.key(), &to_pubkey.key(), amount);
-
-    invoke_signed(instruction, &[from_pubkey, to_pubkey, program_id], signer_seeds)?;
-    Ok(())
-}
-```
-
-The `signer_seeds{:rs}` are passed into `invoke_signed(){:rs}` as the third argument.
-
-</Tab>
-</Tabs>
-
-A reference program containing both approaches is available on [Solana Playground](https://beta.solpg.io/github.com/ZYJLiu/doc-examples/tree/main/cpi-pda).

docs-v2/src/content/docs/basics/idl.mdx

@@ -25,7 +25,7 @@ The `instructions` array in the IDL maps directly to the public functions inside
 
 The program below exposes a single `initialize(){:rs}` instruction along with the `Initialize{:rs}` accounts struct it expects:
 
-<Code code={lib} lang="rust" title="lib.rs" meta="{8-12,15-22} collapse={24-27}" />
+<Code code={lib} lang="rust" title="lib.rs" meta="{8-12,15-22} collapse={23-27}" />
 
 </Tab>
 <Tab>
@@ -53,7 +53,7 @@ The `accounts` array in the IDL maps to every struct annotated with `#[account]{
 
 The program defines a `NewAccount{:rs}` struct with a single `data: u64{:rs}` field:
 
-<Code code={lib} lang="rust" title="lib.rs" meta="{24-27} collapse={5-22}" />
+<Code code={lib} lang="rust" title="lib.rs" meta="{24-27} collapse={4-23}" />
 
 </Tab>
 <Tab>
@@ -151,23 +151,3 @@ b0 5f 04 76 5b b1 7d e8 a1 93 57 2a d3 5e b1 ae e5 f0 69 e2 09 7e 5c d2 64 56 55
 ```
 
 The leading 8 bytes become the discriminator:
-
-```text
-b0 = 176
-5f = 95
-04 = 4
-76 = 118
-5b = 91
-b1 = 177
-7d = 125
-e8 = 232
-```
-
-See the [account discriminator source](https://github.com/solana-foundation/anchor/blob/62865c636aecc6974fc9cfebfc6cf08ca4f0bb72/lang/attribute/account/src/lib.rs#L113-L125) for the implementation.
-
-<Callout variant="note">
-  Two programs that define accounts with the same struct name produce identical discriminators. Anchor avoids confusion at deserialization time by also verifying that the account is owned by the expected program.
-</Callout>
-
-</Tab>
-</Tabs>

docs-v2/src/content/docs/basics/pda.mdx

@@ -140,64 +140,3 @@ pub struct InstructionAccounts<'info> {
 <Tab>
 
 The `init{:rs}` constraint is commonly used with `seeds{:rs}` and `bump{:rs}` to create a new account whose address is a PDA. Under the hood, `init{:rs}` invokes the System Program to create the account:
-
-```rust showLineNumbers=false {5-7}
-#[derive(Accounts)]
-pub struct InstructionAccounts<'info> {
-    #[account(mut)]
-    pub signer: Signer<'info>,
-    #[account(
-        init,
-        payer = signer,
-        space = 8 + 1,
-        seeds = [b"hello_world", signer.key().as_ref()],
-        bump,
-    )]
-    pub pda_account: Account<'info, CustomAccount>,
-    pub system_program: Program<'info, System>,
-}
-
-#[account]
-pub struct CustomAccount {
-    pub bump_seed: u8,
-}
-```
-
-<Callout variant="note">
-  The `init{:rs}` constraint must be used with `payer{:rs}` and `space{:rs}`. The `payer{:rs}` specifies the account that will pay for the account creation. The `space{:rs}` specifies the bytes to allocate for the account (including the 8-byte discriminator).
-</Callout>
-
-</Tab>
-</Tabs>
-
-## PDA seeds in the IDL
-
-PDA seeds defined in the `seeds{:rs}` constraint are included in the program's IDL file. This allows the Anchor client to automatically resolve account addresses using these seeds when constructing instructions.
-
-<Tabs items={['Program', 'IDL', 'Client']}>
-<Tab>
-
-The program below defines a `pda_account{:rs}` using a static seed (`b"hello_world"{:rs}`) and the signer's public key as a dynamic seed:
-
-<Code code={lib} lang="rust" title="lib.rs" meta="{18}" />
-
-</Tab>
-<Tab>
-
-The IDL records the PDA seeds declared on the account. The static seed `b"hello_world"{:rs}` is converted to byte values, and the dynamic seed is included as a reference to the signer account:
-
-<Code code={idl} lang="json" title="idl.json" meta="{16-17,20-21} collapse={3-8}" />
-
-</Tab>
-<Tab>
-
-The Anchor client uses the IDL to automatically resolve the PDA address. The provider wallet acts as the signer, and its public key becomes the dynamic seed for derivation, so the client can call the instruction without explicitly deriving the PDA:
-
-<Code code={client} lang="ts" title="test.ts" meta="{13}" />
-
-When the instruction is invoked, the PDA is printed to program logs:
-
-<Code code={logs} lang="text" meta="{3}" />
-
-</Tab>
-</Tabs>

docs-v2/src/content/docs/basics/program-structure.mdx

@@ -23,7 +23,7 @@ The following program exposes a single `initialize(){:rs}` instruction that crea
 
 The [`declare_id!(){:rs}`](https://docs.rs/anchor-lang/latest/anchor_lang/macro.declare_id.html) macro embeds the program's on-chain address, known as the program ID, into the compiled binary:
 
-<Code code={lib} lang="rust" title="lib.rs" meta="{3} collapse={5-27}" />
+<Code code={lib} lang="rust" title="lib.rs" meta="{3} collapse={4-27}" />
 
 By default, the program ID is the public key of the keypair at `/target/deploy/<program_name>-keypair.json`. To rewrite the `declare_id!(){:rs}` string to match the on-disk keypair, run `$ anchor keys sync{:ansi}`.
 
@@ -100,9 +100,3 @@ The discriminator is the first 8 bytes of `SHA256("account:<StructName>"){:rs}`,
 
 <Callout variant="note" title="Reserving discriminator space">
   Every `init{:rs}` constraint must allocate 8 extra bytes of space for the discriminator in addition to the account's own fields. In the example below, `space = 8 + 8{:rs}` covers 8 bytes for the discriminator plus 8 bytes for the `data: u64{:rs}` field.
-
-  ```rust showLineNumbers=false
-  #[account(init, payer = signer, space = 8 + 8)]
-  pub new_account: Account<'info, NewAccount>,
-  ```
-</Callout>

docs-v2/src/content/docs/clients/rust.mdx

@@ -45,16 +45,3 @@ The `src/main.rs` file drives the program. Two pieces do the work:
 <Code code={main} lang="rust" title="src/main.rs" meta="{13-14,49-75,79}" />
 
 The `Cargo.toml` dependencies:
-
-```toml title="Cargo.toml"
-[package]
-name = "client-example"
-version = "0.1.0"
-edition = "2021"
-
-[dependencies]
-anchor-client = { version = "1.0.0", features = ["async"] }
-anchor-lang = "1.0.0"
-anyhow = "1.0.93"
-tokio = { version = "1.0", features = ["full"] }
-```

docs-v2/src/content/docs/clients/typescript.mdx

@@ -253,55 +253,3 @@ const account = await program.account.newAccount.fetch(ACCOUNT_ADDRESS)
 <Tab>
 
 `program.account.newAccount.fetchMultiple(){:ts}` fetches and deserializes multiple accounts at once, taking an array of addresses:
-
-```ts showLineNumbers=false
-const accounts = await program.account.newAccount.fetchMultiple([
-  ACCOUNT_ADDRESS_ONE,
-  ACCOUNT_ADDRESS_TWO,
-])
-```
-
-</Tab>
-</Tabs>
-
-## Example
-
-The example below uses `@anchor-lang/core` to interact with a simple Anchor program. The program exposes an `initialize{:rs}` instruction that creates and initializes a counter account, and an `increment{:rs}` instruction that increments the stored value.
-
-<Code code={lib} lang="rust" title="lib.rs" />
-
-A typical folder layout for a TypeScript client that interacts with the program looks like this:
-
-<FileTree>
-  <Dir name="ts" open={true}>
-    <Dir name="idl" open={true}>
-      <File name="example.json" />
-      <File name="example.ts" />
-    </Dir>
-    <File name="example.ts" />
-    <File name="package.json" />
-  </Dir>
-</FileTree>
-
-The `/idl` directory contains the IDL itself in `example.json` and a generated TypeScript type definition in `example.ts`. Both files are reproduced below for reference:
-
-<Tabs items={['example.json', 'example.ts']}>
-<Tab>
-
-<Code code={exampleJson} lang="json" title="example.json" />
-
-</Tab>
-<Tab>
-
-<Code code={exampleTs} lang="ts" title="example.ts" />
-
-</Tab>
-</Tabs>
-
-<Callout variant="note">
-  Running `$ anchor build{:ansi}` in an Anchor project regenerates both files automatically: the IDL file at `target/idl/<program-name>.json` (e.g., `target/idl/example.json`) and the TypeScript type definitions at `target/types/<program-name>.ts` (e.g., `target/types/example.ts`).
-</Callout>
-
-The script that drives the program follows:
-
-<Code code={exampleClient} lang="ts" title="example.ts" />

docs-v2/src/content/docs/features/declare-program.mdx

@@ -91,28 +91,28 @@ The caller program imports the generated `cpi{:rs}`, `accounts{:rs}`, and `progr
 
 `declare_program!(){:rs}` takes the IDL filename (without extension) as its single argument:
 
-<Code code={caller} lang="rust" title="lib.rs" meta="{5} collapse={1-3,7-65}" />
+<Code code={caller} lang="rust" title="lib.rs" meta="collapse={1-4,7-65}" />
 
 </Step>
 <Step>
 
 Bring the generated modules into scope:
 
-<Code code={caller} lang="rust" title="lib.rs" meta="{6-13} collapse={1-4,15-65}" />
+<Code code={caller} lang="rust" title="lib.rs" meta="collapse={1-4,14-65}" />
 
 </Step>
 <Step>
 
 Use the imported types in the account validation struct:
 
-<Code code={caller} lang="rust" title="lib.rs" meta="{57-65} collapse={1-55}" />
+<Code code={caller} lang="rust" title="lib.rs" meta="collapse={1-56}" />
 
 </Step>
 <Step>
 
 Use the `cpi{:rs}` module to invoke the callee's instructions:
 
-<Code code={caller} lang="rust" title="lib.rs" meta="{20-32} collapse={1-19,33-65}" />
+<Code code={caller} lang="rust" title="lib.rs" meta="collapse={1-19,33-65}" />
 
 <Code code={caller} lang="rust" title="lib.rs" meta="{34-44} collapse={1-19,45-65}" />
 
@@ -168,21 +168,21 @@ The client script uses the generated `client{:rs}` module to build instructions
 
 `declare_program!(){:rs}` takes the IDL filename (without extension) as its single argument:
 
-<Code code={client} lang="rust" title="src/main.rs" meta="{13} collapse={1-12,14-82}" />
+<Code code={client} lang="rust" title="src/main.rs" meta="collapse={1-12,14-82}" />
 
 </Step>
 <Step>
 
 Bring the generated modules into scope:
 
-<Code code={client} lang="rust" title="src/main.rs" meta="{14-18} collapse={1-13,19-82}" />
+<Code code={client} lang="rust" title="src/main.rs" meta="collapse={1-13,19-82}" />
 
 </Step>
 <Step>
 
 Use the `client{:rs}` module to build the program's instructions:
 
-<Code code={client} lang="rust" title="src/main.rs" meta="{49-58} collapse={1-48,59-82}" />
+<Code code={client} lang="rust" title="src/main.rs" meta="collapse={1-48,59-82}" />
 
 <Code code={client} lang="rust" title="src/main.rs" meta="{60-67} collapse={1-48,68-82}" />
 
@@ -191,14 +191,14 @@ Use the `client{:rs}` module to build the program's instructions:
 
 Add the instructions to a transaction and send it:
 
-<Code code={client} lang="rust" title="src/main.rs" meta="{69-75} collapse={1-68,76-82}" />
+<Code code={client} lang="rust" title="src/main.rs" meta="collapse={1-68,76-82}" />
 
 </Step>
 <Step>
 
 Use the `accounts{:rs}` module to fetch and deserialize the program's account data:
 
-<Code code={client} lang="rust" title="src/main.rs" meta="{79} collapse={1-78,80-82}" />
+<Code code={client} lang="rust" title="src/main.rs" meta="collapse={1-78,80-82}" />
 
 </Step>
 </Steps>

docs-v2/src/content/docs/features/errors.mdx

@@ -116,54 +116,3 @@ pub enum MyError {
 ### `require!(){:rs}`
 
 The [`require!(){:rs}`](https://docs.rs/anchor-lang/latest/anchor_lang/macro.require.html) macro provides a more concise way to handle error conditions. It combines a condition check with returning an error if the condition is false:
-
-```rust title="lib.rs" {5} showLineNumbers=false
-#[program]
-mod hello_anchor {
-    use super::*;
-    pub fn set_data(ctx: Context<SetData>, data: MyAccount) -> Result<()> {
-        require!(data.data < 100, MyError::DataTooLarge);
-        ctx.accounts.my_account.set_inner(data);
-        Ok(())
-    }
-}
-
-#[error_code]
-pub enum MyError {
-    #[msg("MyAccount may only hold data below 100")]
-    DataTooLarge
-}
-```
-
-Anchor provides several `require{:rs}` macros for different validation needs:
-
-- `require!(){:rs}` ensures a condition is true, otherwise returns the given error.
-- `require_eq!(){:rs}` ensures two non-pubkey values are equal.
-- `require_neq!(){:rs}` ensures two non-pubkey values are not equal.
-- `require_keys_eq!(){:rs}` ensures two pubkeys are equal.
-- `require_keys_neq!(){:rs}` ensures two pubkeys are not equal.
-- `require_gt!(){:rs}` ensures the first non-pubkey value is greater than the second.
-- `require_gte!(){:rs}` ensures the first non-pubkey value is greater than or equal to the second.
-
-## Example
-
-The program below validates that an input amount falls within an acceptable range. It defines two custom error variants with messages and uses `require!(){:rs}` to enforce the bounds:
-
-<Tabs items={['Program', 'Client']}>
-<Tab>
-
-<Code code={lib} lang="rust" title="lib.rs" meta="{10-11,21-25}" />
-
-</Tab>
-<Tab>
-
-<Code code={client} lang="ts" title="test.ts" />
-
-</Tab>
-</Tabs>
-
-When a program error occurs, Anchor's TypeScript client SDK returns a detailed [error response](https://github.com/solana-foundation/anchor/blob/62865c636aecc6974fc9cfebfc6cf08ca4f0bb72/ts/packages/anchor/src/error.ts#L51-L71) containing information about the error:
-
-<Code code={errorResponse} lang="shell" title="Error response" />
-
-For a more comprehensive example, see the [errors test program](https://github.com/solana-foundation/anchor/blob/master/tests/errors/programs/errors/src/lib.rs) in the Anchor repository.