-
Notifications
You must be signed in to change notification settings - Fork 13.3k
regression: reached recursion limit while instantiating #79909
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
searched nightlies: from nightly-2020-10-23 to nightly-2020-12-12 bisected with cargo-bisect-rustc v0.6.0Host triple: aarch64-unknown-linux-gnu cargo bisect-rustc |
Underneath the recursion limit error lies a success story. The combine crate generates a lot of dead code and a new implementation is much better at removing it. The most significant aspect is removal of dead dyn casts, since without them there are fewer codegen items. The crate has a configured recursion limit 67, which is exactly what is necessary. Since the codegen item collector uses memoization, removal of dyn cast might increase required recursion depth, which after changes it is at 71. |
Hm, and 67 is lower than the default? I am a bit worried at us exposing such low level details, but it sounds like this should be won't fix. |
Discussed on Zulip and removing |
I am inclined to agree that this is not readily fixable. I am not sure whether we made the right call exposing such internal implementation details to end users - it feels like recursion limits are always going to be error prone for people to configure. However, the limit of 67 configured by this crate is below the minimum Rust by default sets (128 currently) so I am not inclined to be too worried. cc @hirartara as the author of this regressed crate |
@Mark-Simulacrum I think you meant to cc @hiratara |
Hello, I made that crate before only to practice Rust, and it has almost no content. Therefore, we don't need to worry at all if we can't build this crate. Moreover, as far as I remember, the default value of |
Closing as won't fix. |
Would be great to see if this is expected -- I think we've previously seen some issues with combine, so maybe just an old version.
cc @matthewjasper @nikomatsakis
The text was updated successfully, but these errors were encountered: