From f093e89e7faf335db0ed81eb0c4b1aaefe1be438 Mon Sep 17 00:00:00 2001 From: hana <81144685+2501babe@users.noreply.github.com> Date: Tue, 14 Jan 2025 21:29:01 +0000 Subject: [PATCH] last test?? last test??? --- programs/sbf/tests/programs.rs | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/programs/sbf/tests/programs.rs b/programs/sbf/tests/programs.rs index 5a7877eeaa2d06..4210099f27fa75 100644 --- a/programs/sbf/tests/programs.rs +++ b/programs/sbf/tests/programs.rs @@ -130,6 +130,7 @@ fn load_execute_and_commit_transaction(bank: &Bank, tx: Transaction) -> Transact } #[cfg(feature = "sbf_rust")] +#[allow(unused)] // HANA fn execute_transactions( bank: &Bank, txs: Vec, @@ -2559,9 +2560,15 @@ fn test_program_sbf_set_upgrade_authority_via_cpi() { assert_eq!(Some(new_upgrade_authority_key), upgrade_authority_key); } -#[test] +// HANA TODO this one is tricky +// it expects lock exclusion to prevent an upgrade and invoke from going in the same entry +// with simd83, upgrade -> invoke correctly prevents execution just like it would... ok no actually the behavior is fine +// we preserve our essential invariant in both directions: same slot same entry is identical to same slot different entry +// we might want to delete this test and just test (if it isnt tested already) that upgrade write locks the program id +// create the upgrade and invoke tx, take locks for one, ensure the other fails, both directions +// #[test] #[cfg(feature = "sbf_rust")] -fn test_program_upgradeable_locks() { +fn _test_program_upgradeable_locks() { fn setup_program_upgradeable_locks( payer_keypair: &Keypair, buffer_keypair: &Keypair,