Bump pinned Rust toolchain to 1.98.1

[AryanSuvarna]

Summary

Draft to test whether bumping the pinned toolchain fixes the two CI jobs that are currently red on main, #32, and #33: Extensions Tests and the rusttestwasm step of make-sqlite3.

Root cause

• rust-toolchain.toml pins Rust 1.85.0 (unchanged since 2025-06-01, same as upstream).
• libsql-sqlite3/test/rust_suite has no committed Cargo.lock (it is gitignored) and is excluded from the root workspace, so CI resolves its transitive dependencies from scratch on every run.
• Newer releases of those crates need a newer compiler:
  • icu_*, wasm-encoder, wast, wat declare rust-version = 1.88 → Cargo refuses to build (rustc 1.85.0 is not supported by the following packages). This is what main and Fix out-of-bounds read when formatting overlong vector text elements #32 hit.
  • yoke-derive 0.8.3 (published 2026-09-15) declares no rust-version, so even upstream's resolver = "3" (which Syncing main branch with the upstream repo #33 brings in) still selects it — and it uses str::from_utf8 as an inherent method, stabilized in 1.87. This is what Syncing main branch with the upstream repo #33 hits after resolution succeeds.

Change

• rust-toolchain.toml: 1.85.0 → 1.98.1 (current stable).
  • 1.88.0 is the lowest version that satisfies every crate above, and was verified first: all 13 CI jobs passed on commit 37c364c3 with no lint fixes needed. Pinning current stable instead buys headroom before the next crate MSRV bump breaks CI again.
• Note on CI coverage: sqlite3.yml (the make-sqlite3 job) has a libsql-sqlite3/** path filter, so it only ran on this PR while an earlier revision touched a file under that path. It passed on this toolchain pin (commit 07c25236, same rust-toolchain.toml as the current head); the revision since then only removed a comment, so that result stands.

Lint fallout from the newer compiler (second commit)

CI runs with RUSTFLAGS: -D warnings, and 1.98.1 surfaced two lints that 1.85.0 did not have. Fixed in a separate commit so they can be reviewed independently:

• mismatched_lifetime_syntaxes (new in 1.89) — 11 signatures that elide a lifetime on the input (&self / &str) but hide it on the output type (Vec<Column>, PageHdrIter, CursorStep<S>, Cow<str>). Changed to spell the output lifetime as '_, exactly as rustc suggests. No semantic change; this is the lifetime the compiler already inferred.
• unused_assignments — frameno in bottomless-cli's restore loop was only ever copied into BatchReader::new and then incremented, never read (BatchReader tracks its own next_frame_no; the function returns the separate last_received_frame_no). Dead since it was introduced in 4a71b2072a. Removed the local entirely and pass first_frame_no directly.

These were found and verified locally on 1.98.1 with the same flags as CI (cargo check --all-targets --all-features, cargo fmt --check, and the three -p libsql --no-default-features --features {core,replication,remote} checks), all clean.

What to watch in CI

• Extensions Tests and make-sqlite3 should go green (they already did on the first 1.98.1 run).
• Run Checks, Run Tests, Check features failed on the first 1.98.1 run on exactly the lints above; they should be green now.

Scope notes

• Only affects cargo invoked inside this repo (fork CI and the libsql-server image build, whose rust:1.90 base already satisfies this). POS Mobile consumes the fork as a git dependency with its own toolchain and is unaffected.
• Upstream is still on 1.85.0; their CI was last green 2026-08-23, before yoke-derive 0.8.3 shipped, so they will hit the same failure on their next run. Until they bump, this is a one-line divergence.
• Once merged, re-run checks on Fix out-of-bounds read when formatting overlong vector text elements #32 and Syncing main branch with the upstream repo #33 (PR CI checks out a merge with main, so no rebase needed).

[goyox86]

Made a small question.

Please feel free to compare 1.88 with 1.98 with models and check if compatibility is fine in libsql-sqlite3

[goyox86]

Is there any problems going with the latest stable version? Could we check if everything works with currant stable which I think is 1.98.1

[AryanSuvarna]

Yep, checked it — stable is 1.98.1 and I've pinned it to this version. It also has no compatbility issues with libsql-sqlite3.

The only wrinkle was that 1.98.1 needed 12 mechanical lint fixes (-D warnings caught a new lifetime-syntax lint + one dead assignment) whereas 1.88 required none. I think this tradeoff is worth the extra lines of code changes so we don't have to come back here for a while and change the pinned Rust toolchain.

[sle-c]

seems like all tests passed so