INVESTIGATION: Compatibility with Anza fork

[dkcumming]

INVESTIGATION: Compabibility with Anza fork

In order for the Rust code written for applications and libraries to be compatible with the Solana Runtime Environment a fork of the Rust Compiler with the required changes has been made by Anza. The compatibility of stable-mir-json with Solana applications and libraries is therefor dependent on its compatibility with the Anza fork. This issue will document the compatibility with the Anza fork, and detail the intended user experience.

Anza and Stable MIR Differences and Requirements

The Anza Rust fork has these differences:

1. The anza rust fork itself which (of course) tracks different version numbers to origin rust but does not contains minor differences inside the compiler directory, and these differences can be reduced to there being support for a different target added for sbf-solana-solana
2. The standard library thus has it's system platform abstraction layer extended to support the sbf-solana-solana. Certain functionality is restricted here, and the functionality that can interact with the Solana Runtime Environment is called with an extern "C" call to a murmur32 hash of the function name (see link).
3. There are some memory functions implemented in the same fashion as 2. in a fork of the compiler-builtins.

Generally features are removed in this fork, a list of removed features was provided by Lucas in a slack conversation:

There many parts of Rust's libraries gated out behind target_arch = "sbf"  and target_family = "solana"  CFG flags. These are the parts I could find right now:
  a.  Reentrant lock (we don't support multithreading, so locks aren't built).
  b.  Backtrace (on library/std and library/std/sys_common)
  c.  `library/alloc`  and `std/src/alloc.rs` We use different allocation mechanisms.
  d.  `std/src/error.rs` : Backtrace doesn't work on SBF.
  e.  `std/src/hash` : No random or thread_local on SBF.
  f.  `std/src/io` : No IO on SBF.
  g.  `std/src/panic.rs`  and `panicking.rs`: We don't support backtrace nor multithreading, so panics  have different implementations.
  h.  `std/src/process.rs` : There is no process management in SBF.

Stable MIR JSON requires:

1. The inclusion of serialisation of stable MIR included in the compiler, which was merged in this PR
2. Ideally, for the MIR and Stable MIR access points to be similar to the source of nightly-2024-11-29 (or later)

Possible Solutions:

1. It might be tempting to think that because most of the differences are in the std lib and compiler builtins for the Anza fork that it would be possible to keep the Stable MIR nightly version we have been working off so far and plug the std lib and builtins in modularly. However attempting to exchange std lib with compilers is not recommended and is unlikely to succeed - and this would not account for the necessary inclusion of sbf-solana-solana target.
2. Anza upgrades the fork to a recent version of rustc. Lucas mentioned that he was in the process of upgrading the solana fork to version 1.84.0 of rustc. This is stratifies both 1. and 2. the requirements listed for Stable MIR JSON.

User Experience (Assuming Solution 2. is taken)

Users will not have to manage rust compiler dependencies to use TOOL_NAME. Stable MIR JSON can add the updated anza fork as a the supported toolchain. When installing the Koat, the dependency of Stable MIR JSON will build automatically (likely as a cargo dependency from crates.io) and this will automatically install the required toolchain through rustup.