soroban-cli
soroban-cli copied to clipboard
stellar
Adapt to rust 1.84 and wasm32v1-none target
Part of https://github.com/stellar/rs-soroban-sdk/issues/1428 -- just moving us to rust 1.84 and wasm32v1-none for the wasm build (and fixing clippy fallout).
One change is needed, commented inline.
Pushed a fix that undoes the backticks and adds a local clippy-allow. I think this is what you wanted?
Also, we need to think about how this will work for folks with older contracts that use an older version of rustc. So I think for the contract build command we need to choose the target based on the version of Rust installed and in use.
Not sure I understand this -- it's a rare contract that's going to not work on 1.84. Are we typically promising "never upgrading rust versions"?
We'll want to delay merging this closer to / after when the SDK is released so that the init commands that generate the contract Cargo.toml will require a late enough Rust version.
Ok.
I separated the rust upgrade into:
- https://github.com/stellar/stellar-cli/pull/2010
Are we typically promising "never upgrading rust versions"?
No, but existing contracts should be able to continue to build with the new tooling, and existing contracts explicitly refuse to build on anything newer than 1.81. Anyone who has already built contracts, and is building a new contract that they presumedly want to use a new SDK and new CLI for, when they go back and run build on their recent (not actually that old) contract will see build errors.
I think we need a small tweak to branch on the version of Rust. If the version of Rust in use is >= 1.84, use wasm32v1-none, if < 1.84, use wasm32-unknown-unknown. I was wondering if we need to also branch on the SDK version in the contract, but I don't think so.
cc @stellar/devx
A mistake that might be easy for devs to make is that they could have scripts that pull the wasm file from the old target directory, and that file could still be present on disk but not updating. Some ideas:
- CLI output an ℹ️ text block informing the user about the change.
- Or, if the CLI detects a
target/wasm32-unknown-unknownwhen building forwasm32v1-none, or vice-versa, the CLI could delete the other before building, outputting an ℹ️ either informing that it has happened or ❓ checking and waiting for the user to confirm to do it (probably the better thing to do).
If the version of Rust in use is >= 1.84, use
wasm32v1-none, if < 1.84, usewasm32-unknown-unknown.
I think you mean "if < 1.82" right? Versions 1.82 and 1.83 are, AIUI, something we don't ever want anyone compiling with, because they don't support wasm32v1-none but do enable the objectionable target features when building for wasm32-unknown-unknown.
Yes right. I wasn't sure what to do with those versions. But I guess the cli errors?
fyi @ElliotFriend @briwylde08 We may need to update the dev docs as well. This changes the wasm path. Even our getting started guide may need to provide note for this
