Add rust-version field to solana-program to prevent the accidental use of unsupported platform-tools versions

[mvines]

People are accidentally using unsupported versions of rust when building solana programs.

A recent notable occurrence of this is #32133, where people are trying to build solana-program 1.16.1 without installing the 1.16-version of the platform-tools. The resulting error is not obvious and hard to debug. With this patch instead they'll get an immediate error from cargo indicating they're using an unsupported rustc version

Fixes #32133

[brooksprumo]

Omg thank you

[brooksprumo]

For me, here's the info about this field: https://doc.rust-lang.org/cargo/reference/manifest.html#the-rust-version-field

[mvines]

Actually sorry, please hold. I realized this is perhaps not quite right. It's unfortunately not always the case that the Rust stable version we're using for building the validator is the same as Rust version that cargo-build-sbf provides. But hey @dmakarov, how quick are we at upgrading platform-tools with a new Rust stable ships? It would be fantastic if we could make the assumption that whenever we upgrade the master branch to a new Rust stable, we do so for native and sbf

[dmakarov]

Actually sorry, please hold. I realized this is perhaps not quite right. It's unfortunately not always the case that the Rust stable version we're using for building the validator is the same as Rust version that cargo-build-sbf provides. But hey @dmakarov, how quick are we at upgrading platform-tools with a new Rust stable ships? It would be fantastic if we could make the assumption that whenever we upgrade the master branch to a new Rust stable, we do so for native and sbf

platform-tools are upgraded fairly often. However, it takes several weeks to do an upgrade, so it’s impractical to upgrade platform-tools to every stable release. Usually I skip 2-3 releases between upgrades. Monorepo update to use a new version of rust is much simpler and a lot quicker on the other hand. Also on-chain programs usually don’t need the latest rust features so much as may be desirable for the native code.

[mvines]

platform-tools are upgraded fairly often. However, it takes several weeks to do an upgrade, so it’s impractical to upgrade platform-tools to every stable release.

Why does it take so long to do an upgrade? Are there typically a large number of merge conflicts?

[dmakarov]

platform-tools are upgraded fairly often. However, it takes several weeks to do an upgrade, so it’s impractical to upgrade platform-tools to every stable release.

Why does it take so long to do an upgrade? Are there typically a large number of merge conflicts?

The tools consist of 5 components: llvm, compiler-builtins, rust compiler, rust standard libraries, and cargo. Compilers and cargo are relatively easy to upgrade. Rust standard libraries upgrade takes most of the time and labor. The process of reapplying our patches is not fully mechanical. Often rust libraries internal implementations change substantially and it takes time to understand how this affects our patches. When a new release introduces some incompatibility and it causes frictions with dependency crates that solana SDK uses it makes senses to upgrade platform-tools urgently to that release of rust, but to keep in sync with the version of rust that the native solana code uses, seems unnecessary labor.

[mvines]

Ok bringing this out of draft! There's been some changes to my previous approach. Now I'm only attempting to solve the problem of programs being accidentally built with an older platform-tools here, due to the fact that we are currently unable to guarantee rust version consistency between the SBF and the native archs.

• I assume that the SBF tools will always be older than or equal in version to the native builds.
• Rather than sprinkling rust-version fields across all crates, I only add it to solana-program as that's pretty much a requirement for all solana programs currently.

[dmakarov]

* I assume that the SBF tools will always be older than or equal in version to the native builds.

I think in the past there was at least one brief occasion when platform-tools were upgraded to newer rust version before solana monorepo started using that rust version for the native code. It's probably not going to happen often, if ever again.

[mvines]

here's the new output when one tries to build solana-program with an older platform-tools:

$ cargo build-sbf
error: package `solana-program v1.16.1 (/Users/mvines/ws/tmp/test-solana/solana-program-1.16.1)` cannot be built because it requires rustc 1.68 or newer, while the currently active rustc version is 1.62.0-dev

[mvines]

ftr: I broke this up into multiple lines because bash comments and line continuations have conflicting syntax 😭

eg:

foo=$(this \  # THIS COMMENT WON'T WORK
  and # AND ALSO THIS COMMENT WON'T WORK \
  that \
)

[mvines]

#32254 is looking nice, I'll probably rebase this sucker on that PR once it lands and that'll clean up all this ugly bash!

[mvines]

Done, now using the new fancy output from cargo build-sbf --version. Thanks @dmakarov!

@brooksprumo or @yihau - this is ready for review now 🥺

[codecov]

Codecov Report

Merging #32232 (1bce490) into master (f71cf07) will decrease coverage by 0.1%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master   #32232     +/-   ##
=========================================
- Coverage    82.0%    82.0%   -0.1%     
=========================================
  Files         772      772             
  Lines      209322   209322             
=========================================
- Hits       171729   171704     -25     
- Misses      37593    37618     +25     

[yihau]

thank you <3. I love this native solution for inconsistent version!

I'm thinking do we want to put this one to test-sanity step. but current version works for me 😈

[brooksprumo]

lgtm