update rust to 1.60, solana to 1.11.6

[2501babe]

i marked two things in the stake client as #[allow(deprecated)] because after looking at the relevant types in solana-client i dont understand what the correct change is

warning: use of deprecated field `solana_client::rpc_filter::Memcmp::encoding`: Field has no server-side effect. Specify encoding with `MemcmpEncodedBytes` variant instead.
  --> stake-pool/cli/src/client.rs:91:21
   |
91 |                     encoding: None,
   |                     ^^^^^^^^^^^^^^
   |
   = note: `#[warn(deprecated)]` on by default

warning: use of deprecated field `solana_client::rpc_filter::Memcmp::encoding`: Field has no server-side effect. Specify encoding with `MemcmpEncodedBytes` variant instead.
   --> stake-pool/cli/src/client.rs:136:21
    |
136 |                     encoding: Some(MemcmpEncoding::Binary),
    |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

if possible i wanna merge this as is and worry about that later tho

[joncinque]

Looks good! Could you just add an issue to investigate and fix those #[allow(deprecated)]s? Might even be a possible "good-first-issue"

[CriesofCarrots]

i dont understand what the correct change is

(Sorry for the flyby) The correct change should be to use a constructor fn for Memcmp: https://github.com/solana-labs/solana/blob/225cddcffbf453cc05f5c6ca2da74509a3fcde07/client/src/rpc_filter.rs#L147-L161
At a glance, the first should probably be Memcmp::new_raw_bytes(), the second Memcmp::new_base58_encoded(), although I can take closer look if helpful.
Also, just occurring to me we don't have a constructor for base64 encoding, so that should probably be added upstream.

[2501babe]

re: the failures, it looks like the flags for one of the upstream tools (either cargo-test-bpf or cargo-test-sbf) have changed... or, rather, the flags that one of them generates to pass to something else are being rejected by the recipient because perhaps the call chain has changed?

    Finished test [unoptimized + debuginfo] target(s) in 5m 29s
     Running unittests (/home/runner/work/solana-program-library/solana-program-library/target/debug/deps/spl_feature_proposal-2570cef13791f5fb)
error: Unrecognized option: 'arch'
error: test failed, to rerun pass '--lib'
cargo-test-sbf child: /home/runner/.local/share/solana/install/active_release/bin/cargo-build-sbf --manifest-path /home/runner/work/solana-program-library/solana-program-library/feature-proposal/program/Cargo.toml --sbf-out-dir /home/runner/work/solana-program-library/solana-program-library/target/deploy --arch sbf
cargo-test-sbf child: /home/runner/.rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/cargo test --manifest-path /home/runner/work/solana-program-library/solana-program-library/feature-proposal/program/Cargo.toml --features test-bpf -- --nocapture --arch bpf

Error: Process completed with exit code 1.

@dmakarov do you have any insight into this?

[dmakarov]

re: the failures, it looks like the flags for one of the upstream tools (either cargo-test-bpf or cargo-test-sbf) have changed... or, rather, the flags that one of them generates to pass to something else are being rejected by the recipient because perhaps the call chain has changed?

    Finished test [unoptimized + debuginfo] target(s) in 5m 29s
     Running unittests (/home/runner/work/solana-program-library/solana-program-library/target/debug/deps/spl_feature_proposal-2570cef13791f5fb)
error: Unrecognized option: 'arch'
error: test failed, to rerun pass '--lib'
cargo-test-sbf child: /home/runner/.local/share/solana/install/active_release/bin/cargo-build-sbf --manifest-path /home/runner/work/solana-program-library/solana-program-library/feature-proposal/program/Cargo.toml --sbf-out-dir /home/runner/work/solana-program-library/solana-program-library/target/deploy --arch sbf
cargo-test-sbf child: /home/runner/.rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/cargo test --manifest-path /home/runner/work/solana-program-library/solana-program-library/feature-proposal/program/Cargo.toml --features test-bpf -- --nocapture --arch bpf

Error: Process completed with exit code 1.

@dmakarov do you have any insight into this?

I don't know how cargo-test-sbf was started. Any options that appear on cargo test command line after --features test-bpf were added to cargo-test-sbf command line after --. cargo-test-sbf simply forwards these options to cargo test command line. Naturally test harness rejects --arch command line option.

Pull request has been modified.

[2501babe]

the issue with --arch bpf is something in the sdk utils is tacking it on at the end in 1.16 where this didnt happen in 1.15. per jon i tried switching from test-bpf calls to test-sbf calls, which doesnt have this wrapper layer

i think we will still have a few test failures now (im not sure how to run these job on my system and the tests pass when invoked normally so i have to rely on ci) which could be 1.16 changes still to triage

[dmakarov]

the issue with --arch bpf is something in the sdk utils is tacking it on at the end in 1.16 where this didnt happen in 1.15. per jon i tried switching from test-bpf calls to test-sbf calls, which doesnt have this wrapper layer

@joncinque just fixed this in #27221

(im not sure how to run these job on my system and the tests pass when invoked normally so i have to rely on ci)

Could you run the CI script locally?

./ci/cargo-test-bpf.sh token

[dmakarov]

You don't need to specify bpf architecture. It's the default. The option was added to test sbfv2 architecture as means to test the changes in the new architecture.

[2501babe]

after fighting this awhile the two outstanding issues are:

• token tests fail when --arch bpf is removed from the ci script. after going through logs, it looks like the reason this seemed to fix the failures is because it causes the tests that happen to fail to not run at all. i dont know why
• stake pool python client tests fail. i thought this was due to my change to the stake pool cli, but it still fails after reverting it. possibly other things changed with the filters, possibly unrelated. ive been unable to run the python stuff locally

ill try again tomorrow

[dmakarov]

after fighting this awhile the two outstanding issues are:

* token tests fail when `--arch bpf` is removed from the ci script. after going through logs, it looks like the reason this seemed to fix the failures is because it causes the tests that happen to fail to not run at all. i dont know why

* stake pool python client tests fail. i thought this was due to my change to the stake pool cli, but it still fails after reverting it. possibly other things changed with the filters, possibly unrelated. ive been unable to run the python stuff locally

ill try again tomorrow

Adding --arch bpf enables these functions to be compiled

solana-program-library/token/program/src/processor.rs

Lines 1023 to 1027 in 8d88fb6

	#[cfg(target_arch = "bpf")]
	fn delete_account(account_info: &AccountInfo) -> Result<(), ProgramError> {
	account_info.assign(&system_program::id());
	account_info.realloc(0, false)
	}

and

solana-program-library/token/program-2022/src/processor.rs

Lines 1403 to 1407 in 8d88fb6

	#[cfg(target_arch = "bpf")]
	fn delete_account(account_info: &AccountInfo) -> Result<(), ProgramError> {
	account_info.assign(&system_program::id());
	account_info.realloc(0, false)
	}

These #cfg[] annotations should be changed to #[cfg(target_os = "solana")], similarly #[cfg(not(target_arch = "bpf"))] should be changed to #[cfg(not(target_os = "solana"))]. Then cargo-build-sbf will do the right thing without the option --arch bpf.

[joncinque]

These #cfg[] annotations should be changed to #[cfg(target_os = "solana")], similarly #[cfg(not(target_arch = "bpf"))] should be changed to #[cfg(not(target_os = "solana"))]. Then cargo-build-sbf will do the right thing without the option --arch bpf.

That's my fault, I made those changes in a security advisory before we had target_os and didn't think to update them when I finally merged it. I put in #3493 to address that bit for you

[joncinque]

@2501babe let me look into the stake pool failures, it might be due to the minimum stake delegation

[joncinque]

I fixed up the tests, rebased, and reverted your revert of the change, since you did it correctly. I ran a little test against testnet and it was perfect

[joncinque]

I decided to just go the whole way and remove "bpf" everywhere in the code, so our features and everything are aligned now

[2501babe]

ohhh it was the 1.11 change that everything needs to be rent exempt, i understand now

[2501babe]

thank you everyone for your help!!