Chore: bump rust version from 1.89 to 1.91

[connortsui20]

Bumps Vortex up to 1.91 (even though 1.92 is just around the corner).

Fixes the clippy lints that come along with that.

[codspeed-hq]

CodSpeed Performance Report

Merging #5553 will degrade performances by 33.07%

_{Comparing ct/rust-1.91 (fade6aa) with develop (32d834a)}

Summary

⚡ 19 improvements
❌ 22 regressions
✅ 1430 untouched
🆕 7 new
⏩ 242 skipped¹

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
❌	decompress_bitpacking_early_filter[i16, 0.0105]	100.6 µs	112 µs	-10.14%
❌	decompress_bitpacking_early_filter[i16, 0.02]	123.6 µs	138.7 µs	-10.93%
❌	decompress_bitpacking_early_filter[i32, 0.02]	133.4 µs	148.6 µs	-10.21%
❌	decompress_bitpacking_early_filter[i8, 0.03]	151.2 µs	168.7 µs	-10.4%
❌	decompress_bitpacking_late_filter[i8, 0.005]	122.3 µs	136.2 µs	-10.23%
❌	canonical_into_nullable[(10000, 100, 0.0)]	4.1 ms	4.8 ms	-13.83%
⚡	into_canonical_non_nullable[(10000, 10, 0.01)]	312.8 µs	236.1 µs	+32.51%
⚡	into_canonical_nullable[(10000, 1, 0.0)]	66.3 µs	58.6 µs	+13.2%
⚡	into_canonical_nullable[(10000, 1, 0.1)]	89.1 µs	77.8 µs	+14.53%
❌	new_alp_prim_test_between[f64, 32768]	210.3 µs	287.3 µs	-26.79%
⚡	old_alp_prim_test_between[f64, 32768]	356.7 µs	285.6 µs	+24.89%
❌	new_bp_prim_test_between[i16, 32768]	141.9 µs	159.3 µs	-10.91%
❌	new_raw_prim_test_between[i32, 16384]	80.9 µs	90.5 µs	-10.63%
❌	new_raw_prim_test_between[i32, 32768]	140.2 µs	158.6 µs	-11.59%
❌	new_raw_prim_test_between[u32, 16384]	82.1 µs	91.3 µs	-10.02%
❌	new_raw_prim_test_between[u32, 32768]	142.1 µs	160.2 µs	-11.29%
⚡	pco_canonical[(10000, 1.0)]	99 µs	89.8 µs	+10.26%
❌	decompress[u8, (1000, 4)]	13.6 µs	15.8 µs	-14.08%
❌	decompress[u8, (10000, 16)]	27.3 µs	33 µs	-17.45%
❌	decompress[u8, (10000, 4)]	73.4 µs	96.8 µs	-24.23%
...	...	...	...	...

ℹ️ Only the first 20 benchmarks are displayed. Go to the app to view all benchmarks.

Footnotes

1. 242 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[codecov]

Codecov Report

❌ Patch coverage is 75.00000% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.43%. Comparing base (cd80330) to head (fade6aa).
⚠️ Report is 32 commits behind head on develop.

Files with missing lines	Patch %	Lines
vortex-array/src/expr/exprs/dynamic.rs	0.00%	1 Missing ⚠️
vortex-buffer/src/bit/buf.rs	0.00%	1 Missing ⚠️
vortex-duckdb/src/scan.rs	0.00%	1 Missing ⚠️

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[connortsui20]

Are these regressions expected with a compiler update?

[0ax1]

Are these regressions expected with a compiler update?

Different inlining behavior or the linker change maybe: https://blog.rust-lang.org/2025/09/01/rust-lld-on-1.90.0-stable/

[a10y]

Why is this necessary?

[AdamGS]

Even with resolver changes, given our versioning, this is a breaking change, we made a small jump recently, I think it's good to keep it at a commonly adopted version.

[connortsui20]

Why is this necessary?

Well I don't think it is strictly necessary, but following that logic there probably isn't ever a reason to upgrade versions to begin with if the language is turing-complete...

Personally, I feel that we should be following the Rust stable toolchain much more closely and consistently rather than waiting until we "need" it. That could give us a huge mountain of fixes we need to make all at once (and in turn, our consumers would probably need to make those changes too).

Since there are regressions here we definitely should look more into this before merging, but in general I think waiting too long to update the rust version can only be a bad thing.

[connortsui20]

In that case we should plan this for the next vortex release? By that time Rust will have moved on to 1.92 so that seems reasonable

[a10y]

I think my stance is something like this:

1. MSRV bumps are very likely to cause friction
2. 1.89 is < 3 months old, so I don't think I agree on the "waiting too long" point. To compare, DF has MSRV 1.88
3. Anyone using Vortex is free to use a toolchain ahead of our MSRV
4. We are free to use nightly/newer stable toolchain to run w/e CI checks we want (we already use nightly to run the formatter checks)

I also think given the recent poke in the TSC meeting around stability and some semblance of a release process, we should really have a reason to bump MSRV, and not just do it by default. My $0.02

[connortsui20]

@a10y I understand that, but to echo what I said on Slack, doing that effectively locks us in to a version. As time goes by, the effort required to upgrade increases, and when we inevitably need to upgrade to a new version (because vortex is far from a "done" state), that process will be super painful for all parties involved.

Maybe we are fine with that? Specifically for Vortex, which seems to have a very high velocity of change, this feels quite strange to me.

Also, I'm not sure that API stability for our consumers is the same as MSRV stability in terms of what a consumer needs to change if we break each one. AFAIK this only matters if they have -Zminimal-versions, which I feel the entire Rust community has effectively given up on.

[a10y]

when we inevitably need to upgrade to a new version (because vortex is far from a "done" state), that process will be super painful for all parties involved

Can you explain this more? I feel like I'm missing something. Clearly this diff PR (which is pretty much just clippy lints?) isn't too burdensome. What is the pain we think we're inflicting by not upgrading MSRV? Why do we think that's greater than the pain caused by forcing everyone to upgrade?

doing that effectively locks us in to a version

I don't think that is the alternative. I think the alternative is having some cadence or framework that dictates when we bump MSRV, e.g. every 4 months, or every 6 months, or every 3 stable releases, or something like that.

[connortsui20]

Ok I think we're on the same page then, I was arguing against never bumping MSRV until we need it, and arguing that whatever we choose it has to be consistent (whether that be a cadence or trailing).

Or to be more specific, if we are consistent in never bumping MSRV, then imo that creates more problems than it solves