Upgrade litesvm to 0.13.1 and solana-kite to 0.4.0 repo-wide; remove sbpf pin#93
Merged
Merged
Conversation
litesvm 0.13.1 (Agave 4.0) natively loads sbpf's SBPF v3 (0x03 OS-ABI) output, so the sbpf revision pin added to work around litesvm 0.11.0 is no longer needed. - Bump litesvm 0.11.0 (and one 0.6.1) -> 0.13.1 across all crates and the workspace root - Bump solana-kite 0.3.0 -> 0.4.0 across all crates. solana-kite 0.4.0 requires litesvm ^0.13.1 and relaxes solana-instruction to >=3.2 so it coexists with litesvm 0.13.1's =3.2.0 pin (0.3.0 required ^3.3.0, which blocked the upgrade) - Remove the sbpf --rev pin so sbpf HEAD (SBPF v3) is used - Regenerate the committed Cargo.lock files (root, escrow/native, shank-and-codama) The four asm examples were verified green on litesvm 0.13.1 with unpinned sbpf; all other suites move to the same versions for consistency.
mikemaccana
force-pushed
the
claude/solana-examples-ci-asm-jb73x0
branch
from
c3776fc to
f5a1c3f
Compare
mikemaccana
changed the title
block-list/pinocchio was pinned to solana-sdk 2.x, so its litesvm host test did not compile after litesvm was bumped to 0.13.1 (Agave 4.0, solana 3.x Address/Instruction types). Port the host-side code to solana 3.x so its types unify with litesvm 0.13.1. The pinocchio on-chain program (program/src) is unchanged. - sdk/rust (generated block-list-client): replace solana-program 2.2.1 with the granular solana 3.x crates (solana-pubkey/instruction/account-info/ program-error/cpi 3.x) and borsh 1.6.1; solana-program 4.0's Pubkey pulls borsh 1.x which clashed with the client's borsh 0.10 - program dev-dependencies: replace solana-sdk 2.2 with granular solana 3.x crates; bump spl-token-2022 7.0 -> 10.0.0 and spl-associated-token-account 6.0 -> 8.0.0 (the solana-3.x-native releases; 9.0/7.0 are still solana 2.x) - tests/test.rs: import the granular solana 3.x crates; system_program::id() -> solana_system_interface::program::ID. Test logic unchanged. Verified: `cargo check --tests` (program) and `cargo check` (sdk/rust) both compile with zero errors.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Moves the whole repo to litesvm 0.13.1 (Agave 4.0) and solana-kite 0.4.0, and removes the temporary
sbpfrevision pin.Why
The
sbpfpin (merged in #86) was a workaround for litesvm 0.11.0 rejecting sbpf's SBPF v3 (0x03OS-ABI) output. litesvm 0.13.1 loads SBPF v3 natively — verified: the four asm examples built with unpinned sbpf and passed on 0.13.1 in an earlier CI run. The only blocker to the upgrade was solana-kite 0.3.0 requiringsolana-instruction ^3.3.0(incompatible with litesvm 0.13.1's=3.2.0); solana-kite 0.4.0 relaxes that to>=3.2.Changes
litesvm0.11.0/0.6.1→0.13.1across all crates and the workspace root.solana-kite0.3.0→0.4.0across all crates.sbpf --revpin so sbpf HEAD (SBPF v3) is used.Cargo.lockfiles (root,escrow/native,shank-and-codama).Verification
Rebased onto current
main.