Compile error for release builds on nightly: overflow evaluating the requirement `<impl GeometryTrait<T = f64>
Hi Kyle,
There is a problem with a vanilla build of 0.2.0 on nightly ('nightly-aarch64-apple-darwin'), on stable ('stable-aarch64-apple-darwin') it compiles fine.
I ran rustup update to try the latest nightly, so i can confirm its not just on one nightly.
Steps to reproduce
cargo new geoarrow_test
cd geoarrow_test
cargo add geoarrow
cargo build --release
Cargo.toml
[package]
name = "geoarrow_test"
version = "0.1.0"
edition = "2021"
[dependencies]
geoarrow = "0.2.0"
Compile Error
Compiling geoarrow v0.2.0
error[E0275]: overflow evaluating the requirement `<impl GeometryTrait<T = f64> as geo_traits::geometry::GeometryTrait>::GeometryCollection<'_>: geo_traits::geometry_collection::GeometryCollectionTrait`
|
= help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`geoarrow`)
note: required for `GeometryCollectionIterator<'_, f64, ..., ...>` to implement `Iterator`
--> /Users/andy/.cargo/registry/src/index.crates.io-6f17d22bba15001f/geoarrow-0.2.0/src/geo_traits/iterator.rs:38:15
|
36 | ItemType: 'a + $item_trait<T = T>,
| ----- unsatisfied trait bound introduced here
37 | G: $self_trait<T = T, ItemType<'a> = ItemType>,
38 | > Iterator for $struct_name<'a, T, ItemType, G>
| ^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
108 | / impl_iterator!(
109 | | GeometryCollectionIterator,
110 | | GeometryCollectionTrait,
111 | | GeometryTrait,
112 | | geometry_unchecked
113 | | );
| |_- in this macro invocation
= note: required for `GeometryCollectionIterator<'_, f64, ..., ...>` to implement `IntoIterator`
= note: the full name for the type has been written to '/Users/andy/rust/test/geoarrow_test/target/release/deps/geoarrow-1b938d32aa0c667b.long-type-6547768600814213466.txt'
= note: consider using `--verbose` to print the full type name to the console
= note: the full name for the type has been written to '/Users/andy/rust/test/geoarrow_test/target/release/deps/geoarrow-1b938d32aa0c667b.long-type-6547768600814213466.txt'
= note: consider using `--verbose` to print the full type name to the console
= note: this error originates in the macro `impl_iterator` (in Nightly builds, run with -Z macro-backtrace for more info)
For more information about this error, try `rustc --explain E0275`.
error: could not compile `geoarrow` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
Environment
rustc -V rustc 1.82.0-nightly (4074d4902 2024-08-23)
Mac Air M1
uname -a Darwin apps4u 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:16:51 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T8103 arm64
Attached file
The file mentioned in the error report
Can you test on latest main? (Or on 0.3.0-beta.2, which I released yesterday)
Also, is there a reason why rust nightly would have different behavior here? I haven't seen this with the rust 1.81.
Still an issue on geoarrow v0.3.0-beta.2, checked out from github main branch, same error.
As to why the issue is only with nightly and only with release builds I dont know.
It is possible that it is a compiler error, maybe we could get some insight on the Rust Zulip channel.
...
Compiling geoarrow v0.3.0-beta.2 (/opt/git/geoarrow-rs)
error[E0275]: overflow evaluating the requirement `impl GeometryCollectionTrait<T = f64>: geo_traits::geometry_collection::GeometryCollectionTrait`
|
= help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`geoarrow`)
note: required for `GeometryCollectionIterator<'_, f64, <... as GeometryCollectionTrait>::ItemType<'_>, ...>` to implement `Iterator`
...
consider increasing the recursion limit by adding a
#![recursion_limit = "256"]attribute to your crate (geoarrow)
I mean that's a very reasonable thing to do. we mostly need this recursion because a geometry can contain geometry collections
consider increasing the recursion limit by adding a
#![recursion_limit = "256"]attribute to your crate (geoarrow)I mean that's a very reasonable thing to do. we mostly need this recursion because a geometry can contain geometry collections
I dont think thats the case, because it compiles fine on stable and nightly + debug.
It may be a regression in the nightly compiler, I linked this issue to the compiler issue to see if that is the case, after asking on the Zulip compiler channel. If you need me to test anything let me know.
Ah, it does look similar to that compiler bug. I'll hold off on adding #![recursion_limit = "256"], but hopefully never has that much geometry - geometry collection - geometry recursions 😄