-
Notifications
You must be signed in to change notification settings - Fork 12.2k
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
New "infinite recursion" error in latest nightly (2023-04-21) #110656
Comments
On further reflection I think I understand why I have also convinced myself that my code is at fault, though since it used to work, it may be prudent to change the compiler to merely warn on this for a few iterations, or something. |
Duplicate of #110475 (same report, same root cause conclusion too. Neat) |
@saethlin thank you for finding this! I only checked the open issues from the last 24 hours since I wasn't able to reproduce the issue until the most recent nightly. |
Indeed, it looks like trying to use this method will cause a compilation error on any compiler -- but one that includes a line number, and one that only occurs when used. So that answers my "how did this ever work?" confusion. It didn't :). However, what has changed is that even code that doesn't use the offending funciton, now fails to compile. |
I'm going to close this as a duplicate. |
I will spend a bit of time minimizing this, but I'm filing an issue now while the details are fresh in my head, since I might not have time until tomorrow.
My crate has the following recursive function which takes a
FnMut
pred
and then calls itself with&mut pred
. This causes an infinite chain of&mut &mut &mut ...
for the compiler when trying to resolveF: FnMut
. This seems natural enough except that this code has been present for at least 2 years, and has worked fine until the 2023-04-21 nightly. The 2023-04-20 will accept it.Specifically the error is
There is a workaround, which is to replace the offending
&mut pred
with&mut |key| pred(key)
, but I don't understand exactly what type magic is going on here that makes one okay but not the other. It never occurred to me to use this form except that I showed this error to GPT4 and that's what it suggested I do.My questions are then:
&mut |key| pred(key)
break the recursion? Thoughout my codebase, but not here for some reason, I have a number of functions that take&mut F
withF: FnMut
rather than directly takingF
. I call these functions names likereal_for_each
and then call them from the API-exposedfor_each
which directly takesF
. Is this closure trick an alternative solution to avoiding compiler errors?The text was updated successfully, but these errors were encountered: