[jira] [Updated] (SPARK-59989) Pin the Rust toolchain and silence double_must_use on async_trait traits

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SPARK-59989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ASF GitHub Bot updated SPARK-59989:
-----------------------------------
    Labels: pull-request-available  (was: )

> Pin the Rust toolchain and silence double_must_use on async_trait traits
> ------------------------------------------------------------------------
>
>                 Key: SPARK-59989
>                 URL: https://issues.apache.org/jira/browse/SPARK-59989
>             Project: Spark
>          Issue Type: Sub-task
>          Components: Connect
>    Affects Versions: connect-gateway-0.1.0
>            Reporter: L. C. Hsieh
>            Assignee: L. C. Hsieh
>            Priority: Major
>              Labels: pull-request-available
>
>   main's CI has been failing since 2026-10-04 on a commit that changed nothing
>   relevant. rust-toolchain.toml pins `channel = "stable"`, so CI picked up the
>   newly released Rust 1.99.0, whose clippy added the double_must_use lint.
>   The lint fires on every `#[async_trait]` trait in the workspace. async_trait
>   expands each method into one returning a `#[must_use]` Pin<Box<dyn Future>>,
>   and the lint then objects that the inner type -- a Result, Option or String --
>   is already must-use. The attribute belongs to the macro expansion, not to our
>   code, so there is nothing in these traits to restructure.
>   Two parts to the fix.
>   Pin the toolchain to 1.99.0. A floating channel means CI can turn red on a
>   commit that changed nothing, at an unpredictable time, whenever upstream Rust
>   ships a new lint or changes behaviour -- which is exactly what happened. A
>   pinned version makes the build reproducible between contributors and CI, and
>   turns a toolchain upgrade into a reviewable change of its own rather than an
>   event that arrives on its own schedule. The file carries that rationale and the
>   steps for moving the pin. The cost is that Rust upgrades become manual; that
>   seems clearly better than the alternative. MSRV is unaffected: rust-version
>   stays at 1.82, which is the minimum this compiles with, a separate thing from
>   the version used to develop and gate.
>   Allow the lint at the two traits it fires on, with a comment explaining it is
>   the macro's attribute rather than ours.
>   Worth flagging a detail about the scope. The CI log named only
>   crates/routing/src/lib.rs, because cargo stopped after that crate failed.
>   Reproducing on 1.99.0 locally showed crates/auth/src/lib.rs:60 is affected as
>   well, so fixing what the log reported would have left CI red on the next run
>   with a different crate named. Both are fixed here.
>   Verified on 1.99.0 throughout, since that is what CI resolves to and 1.97.1 --
>   what a contributor might have locally -- does not reproduce the failure at all:
>   - The failure reproduces before the change: 6 errors, matching CI.
>   - cargo +1.99.0 clippy --workspace --all-targets -- -D warnings is clean after.
>   - cargo +1.99.0 fmt --all --check is clean.
>   - cargo +1.99.0 test --workspace is 204 passed, 0 failed, 10 ignored.
>   - A bare `cargo` now resolves to 1.99.0 via rust-toolchain.toml and passes,
>     confirming the pin takes effect for contributors and CI rather than only when
>     the version is named explicitly.
>   This unblocks #43 (SPARK-59973), which is red for this reason and not for
>   anything in its own diff.



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

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@spark.apache.org
For additional commands, e-mail: issues-help@spark.apache.org