-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Condition types do not support non-static-lifetime borrowed pointers #5370
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
�The case documented by brson in the description seems like it works now (after updating the
... however, my attempt to investigate more carefully (by putting in a use of the condition) yielded similar problems:
and:
So I am going to leave this ticket open for now. The test case in the description should probably be revised to something that exposes the bug, but I do not like my current examples (they are the results of my playing around, and do not necessarily denote a sane scenario), so I am going to wait to come up with something better before revising the description. |
Re-nominating for milestone 3, feature-complete. I don't think this is backwards-incompatible. |
accepted for backwards-compatible milestone |
FYI, the examples I provided now consistently yield the error:
I'm reviewing to see if this means we can close this ticket. Update (later): Well, duh, the title of the ticket says that this is still a problem. so the question is whether we actually want to support this or not. Since condition handlers are executed in the context of where they are raised, it sounds like we should be able to do this. The current problem arises due to the implementation strategy we are using; I do not think it is intrinsic to the feature itself (of offering a condition system, at least not one where the handlers are executed in the dynamic context of where the raise occurred, so that all borrowed state should indeed still be available). |
cc #9795 |
|
Remove dependency on `matches` crate The std equivalent works exactly the same. changelog: none
The text was updated successfully, but these errors were encountered: