Move rust-toolchain.toml to root dir #1161
Merged
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.
What
Move rust-toolchain.toml to root dir.
Why
The file should live at the top of the rust workspace, which is the root directory of the repository.
The file is currently living inside the soroban-cli directory because the repository used to be only the soroban-cli. It's likely we didn't intend to leave it in a sub-directory and it's current location is accidental.
By moving it to the root it'll inform Rust tooling and IDEs which toolchain to use, and what target and components need to be installed for developing in the repo.
It's channel is set to stable which means that development and builds during release will happen with the latest stable. This is fine. As of #1159 we always test with both the minimum supported rust version (msrv) and the latest stable version, so any release we do should have been tested prior with the same version.
Note that some applications we have, like stellar-core, build and release with a fixed and specific version of stellar-core. That's so that we retain complete control over what version of Rust gets used. But for software less critically impacted by a possible divergence in behavior can keep using stable. Soroban RPC does embed soroban-env and so there's some risk of divergence, but I don't think it's something we should mitigate by pinning here. Instead we should rely on testing as much as possible to identify problems, and if the tests miss something a divergence in soroban-rpc's preflight logic would have minimal impact compared to the same in stellar-core.
Close stellar/rs-soroban-env#1311