mbutrovich commented on PR #10351:
URL: https://github.com/apache/arrow-rs/pull/10351#issuecomment-4993593624
The failing MSRV check is not specific to this PR (which only touches
`parquet/`, the `parquet-testing` submodule, and the MSRV workflow).
**Cause:** no `Cargo.lock` is committed, so `cargo msrv verify` resolves
fresh each run. With `resolver = "2"` (not rust-version-aware) it selects the
newest dep versions, which now exceed MSRV 1.85 -- e.g. `tonic 0.14.6` requires
1.88. The `--locked` change on this branch surfaced it by getting the job past
`cargo install cargo-msrv`.
**`main` reproduces it.** `cargo msrv verify` on `main`'s HEAD tree, 1.85
toolchain:
```
error: rustc 1.85.0 is not supported by the following packages:
[email protected] requires rustc 1.88
```
`main`'s CI is currently green, which appears to be a cached registry index
(predating `tonic 0.14.6`); a cold resolve fails.
**Two fixes verified locally (`cargo msrv verify`, 1.85):**
- `resolver = "3"` (edition 2024 default): `is_compatible: true` --
back-selects `tonic 0.14.5`, `icu 2.1.x`. Covers any dep declaring a
`rust-version`.
- Manual `cargo update -p <crate> --precise` pins in the MSRV job (as in
#7290): also works; one entry per offender.
**Questions for @alamb:**
1. Preference between the two approaches above?
2. Land on `main` first (since it has the same latent failure), then
backport to `58_maintenance`?
The C Data Interface (Java to Rust) failure appears unrelated (Java
allocator leak).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
