Regression: geoarrow crate does not compile in release mode on 1.82

[theemathas]

This issue is originally reported by @kylebarron at #128887 (comment)

The geoarrow crate does not compile in release mode on rust 1.82.0, despite compiling fine in debug mode or in rust 1.81.0.

The code can be obtained by:

git clone https://github.com/geoarrow/geoarrow-rs
cd geoarrow-rs
git checkout 0b6715c6a56f0115f9078803fae945700713b22f

The following commands give compilation errors:

rustup run 1.82 cargo build --release
rustup run nightly cargo build --release

The following commands compile fine without errors:

rustup run 1.81 cargo build --release
rustup run 1.81 cargo build
rustup run 1.82 cargo build
rustup run nightly cargo build
RUSTFLAGS='-Zinline-mir=no' rustup run nightly cargo build --release

Note that this is issue is distinct from the previous 1.80-to-nightly geoarrow regression, which is fixed in #129714 and tested in #129757.

@rustbot labels regression-from-stable-to-stable

[saethlin]

Note that this is issue is distinct from the previous 1.80-to-nightly geoarrow regression, which is fixed in #129714 and tested in #129757.

No, I'm pretty sure this is exactly the same problem. I see 128 recursive calls to mir_callgraph_reachable::process with -Ztreat-err-as-bug.

[saethlin]

We would also need a magic -3 adjustment on top of the existing recursion limit hack to make this compile. I could speculate but I don't think I understand why. I think it's pretty clear though that's the regression test we checked in doesn't cover the scenario that geoarrow is hitting.

[lqd]

Bisects to nightly-2024-08-02, seemingly #127159 within rollup #128461. But it makes no sense, so there may be some other weirdness going on.

[saethlin]

cc @compiler-errors

At the current time, I'm not working on any fix for this regression. I'm really not sure what a reasonable change would be; we can add some more magic numbers to the cycle avoidance recursion limit, but I'm not sure what number we can add that's reasonable. I suspect that whatever we do, there will be some type that someone can write that will run into this error anyway.

It's my understanding that this error can be fixed in the new trait solver, but that won't land for so long that it's kind of off topic for this issue.

I feel like there should be a better way to write the cycle avoidance call graph code, but I don't know if this scenario can be avoided by that.