Skip to content

build(cargo): Update Rust toolchain to 1.90.0#4457

Merged
har7an merged 14 commits into
zellij-org:mainfrom
har7an:toolchain/rust-edition-2024
Oct 6, 2025
Merged

build(cargo): Update Rust toolchain to 1.90.0#4457
har7an merged 14 commits into
zellij-org:mainfrom
har7an:toolchain/rust-edition-2024

Conversation

@har7an
Copy link
Copy Markdown
Contributor

@har7an har7an commented Oct 4, 2025

Replace the previously used (and now EOL) Rust toolchain 1.84.0 with the currently stable 1.90.0. The versions in between didn't bring any radically new changes that affect our code as far as I could tell. However, there has been a significant improvement in development iteration times. See more on that below.

Apart from that, I took the time to deduplicate some of our cargo manifest keys, including crate licenses and rust versions. This change is made in a spirit similar to #4085, where I did pretty much the same with our crate dependencies. During this migration I noticed that the plugin-manager and session-manager were still using the 2018 Rust edition. I updated both crates to use Rust edition 2021 like the rest of the codebase does. Finally, this removes an obsolete build script that had been introduced during the migration from makers to cargo xtask to handle protobuf compilation for the WASM plugins.

Development Performance Improvements

Rust 1.90.0 brings in a very nice change: The default linker on Linux GNU is now lld. I ran a little benchmark to verify this. First I did a cargo clean && cargo xtask build to make sure all dependencies were built already. Then I wrote a script called bench.sh with the following content:

#!/usr/bin/env bash

cargo clean -p "zellij"
exec cargo build

Sidenote: Running this in a shell of course adds overhead to execution times from shell stuff, but in this case the runtime of linking far surpasses any shell setup so this is fine.

Tested on the HEAD commit of this branch this was the result:

$ hyperfine ./bench.sh
Benchmark 1: ./bench.sh
  Time (mean ± σ):      3.275 s ±  0.310 s    [User: 6.280 s, System: 5.697 s]
  Range (min … max):    3.058 s …  4.036 s    10 runs

Whereas with Rust 1.89.0 (commit fec4e69), this is what I got:

$ hyperfine ./bench.sh
Benchmark 1: ./bench.sh
  Time (mean ± σ):     17.478 s ±  0.658 s    [User: 12.322 s, System: 5.505 s]
  Range (min … max):   16.487 s … 18.412 s    10 runs

So in essence, iteration times should be significantly faster now. Similar improvements can be seen when using cargo q or cargo xtask build --quick-run. Yay!

har7an added 12 commits October 6, 2025 16:48
in order to allow workspace members to easily copy their values, rather
than copying the actual values manually between files. Prepare for a
future update of the Rust edition this way by defining the edition in
one central location.
and don't copy the actual license value manually between crates.
rather than manually defining the value per crate. There is no
apparent advantage in having different parts of the code use different
rust editions. It only makes the code inconsistent, which is not a goal
worth striving for.
at least for those workspace members that are versioned in lockstep.
from edition 2018 in order to use a single unified Rust edition across
the entire workspace. Apparently the migration does not involve changes
to the actual code.
from edition 2018 in order to use a single unified Rust edition across
the entire workspace. Apparently the migration does not involve changes
to the actual code.
which has contained nothing but comments for two years now. The initial
"workaround" has by now become the proper solution and the original
issue (see <zellij-org#2711>) has never
been heard of since.

The real motivation for this change is the simple fact that this version
of prost-build pulled in a pretty old version of the `which` crate which
doesn't appear to build with Rust 1.89 (latest stable as of now).
which is the latest stable toolchain as of writing this and has support
for the 2024 Rust edition, unlike the previously used 1.84.
in cases where a functions return type has an actual lifetime that
depends on a non `'static` argument.
which is the latest stable toolchain as of writing this. Compared to
1.89.0 this changes the default linker and should, hence, cut down
iteration times during development significantly.
for the tagged release assets. Previously the rust version was
unconditionally overwritten to be `stable` regardless of what
`rust-toolchain.toml` configured.
@har7an har7an force-pushed the toolchain/rust-edition-2024 branch from 5c2690e to 356a457 Compare October 6, 2025 14:48
to list of unreleased changes.
since it no longer resides directly in the `package` object.
@har7an har7an merged commit 80de7f4 into zellij-org:main Oct 6, 2025
7 checks passed
@har7an har7an deleted the toolchain/rust-edition-2024 branch October 6, 2025 17:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant