You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@thrift.apache.org by "Jens Geyer (Jira)" <ji...@apache.org> on 2026/08/29 12:46:00 UTC

[jira] [Created] (THRIFT-6162) Rust: documented MSRV (1.65) is neither built nor enforced and conflicts with the pinned toolchain (1.85.1)

Jens Geyer created THRIFT-6162:
----------------------------------

             Summary: Rust: documented MSRV (1.65) is neither built nor enforced and conflicts with the pinned toolchain (1.85.1)
                 Key: THRIFT-6162
                 URL: https://issues.apache.org/jira/browse/THRIFT-6162
             Project: Thrift
          Issue Type: Improvement
          Components: Rust - Library
            Reporter: Jens Geyer


The Rust binding documents a minimum supported Rust version that nothing builds, enforces, or verifies, and that no longer matches what the tree actually needs.

h3. Current state

* {{lib/rs/README.md}} ("Compatibility") states: "The Rust library and auto-generated code target Rust versions 1.65+. [...] Enabling the optional {{rustls}} feature requires Rust 1.71+."
* {{rust-toolchain}} (repo root) pins {{1.85.1}} (raised in "Rust: re-enable dedicated CI job with toolchain 1.85.1").
* {{.github/workflows/build.yml}}, {{lib-rust}} job: {{TOOLCHAIN_VERSION: 1.85.1}}.
* {{.github/workflows/release_rust.yml}} pins {{1.85}}, with the comment: "The repo-pinned toolchain (rust-toolchain: 1.83) predates edition2024 support required by transitive dependencies (getrandom >= 0.4); 1.85 is the minimum that passes."
* {{lib/rs/Cargo.toml}} has no {{rust-version}} key.

So no build anywhere -- CI, docker, or release -- ever compiles at the documented 1.65 floor. The number is a claim in prose only.

h3. Where the 1.85 requirement comes from

{{uuid 1.25.0}} depends on {{getrandom 0.4.3}}, which is edition 2024 and therefore needs rustc 1.85+.

Note the nuance: {{lib/rs/Cargo.toml}} declares {{uuid = "1"}} under {{\[dependencies\]}} with no features, and {{uuid = { version = "1", features = \["v4"\] }}} under {{\[dev-dependencies\]}}. The {{getrandom}} edge comes from the {{v4}} feature. That means there are two distinct numbers currently conflated under one README sentence:

* the floor to *build and test this repository* (dev-dependencies active) -- demonstrably 1.85;
* the floor for a *downstream consumer of the published crate* with default features -- possibly lower, and currently unmeasured.

h3. Decision needed

Two directions, and I do not have a strong preference:

* *Option A -- make 1.65 real.* Add a CI job that builds {{lib/rs}} at the documented MSRV so the promise is actually exercised, and adjust dependency constraints until it passes. Keeps the compatibility promise to downstream users pinned to older toolchains.
* *Option B -- document reality.* Measure the true floor (separately for default features and for the {{rustls}} feature, as the README already distinguishes 1.65 vs 1.71) and update the README to that number.

h3. Do this either way

Add a {{rust-version}} key to {{lib/rs/Cargo.toml}}. Cargo then enforces the floor: it fails with an explicit "requires rustc X" message rather than confusing syntax errors from a too-old compiler, and it warns when a dependency bump would raise the floor -- which is exactly the drift that produced the current mismatch.

The *value* of that key depends on which option above is chosen, so the Cargo.toml change cannot land before the decision is made.

h3. Not caused by any open PR

This predates and is independent of the current Rust work. It surfaced while reviewing a dependency swap (THRIFT-6159 / PR #3739), where "CI is green" turned out not to be evidence of MSRV compliance, precisely because no build exercises the documented floor.

----
Reported with AI assistance (Claude Opus 5).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)