-
Notifications
You must be signed in to change notification settings - Fork 443
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
Breaking change involving RefUnwindSafe in 1.1.3 #568
Comments
It appears that using a trait object internally implies that the containing type cannot be assumed to be UnwindSafe. This wasn't previously an explicit API guarantee, but the AhoCorasick automaton in 0.6.x was UnwindSafe and it's probably a good idea to keep that particular feature. Here, we satisfy that by requiring Prefilter to be UnwindSafe, so that all Prefilter trait objects are therefore also UnwindSafe. In particular, this introduced a regression in regex that caused a regex to not be UnwindSafe because it contained an AhoCorasick automaton. See rust-lang/regex#568 for details.
@dtolnay Thanks for the bug report! This was definitely not intentional. I've fixed this in I'll confess that the UnwindSafe marker trait hasn't been something that I've been keeping a keen eye on. In particular, it seems incredibly easy to foul this up whenever one uses trait objects. But I guess it's the same situation as with In this particular circumstance, I fixed it by just making Advice is welcome if you think there's anything else I should be doing! (I have now added marker trait tests on regex's public API, so this particular regression shouldn't happen again.) |
Thanks for the quick fix! I was unfamiliar with this failure mode too. I guess it is not so common to add new trait objects into a struct and not so common to use catch_unwind, so they don't intersect much. |
@BurntSushi https://github.com/rust-lang/regex/blob/1.1.4/Cargo.toml#L29 looks like Turbo87/ogn-web-gateway#139 seems to be breaking due to that |
@Turbo87 No, there was a typo in my comment above. Your build is breaking because of an unrelated reason. Compare the output of your build to the error reported in this ticket, for example. I filed a separate bug here: #570 (Which is now fixed in regex 1.1.5.) |
I see. thanks for the quick response! ❤️ |
The following code compiles against regex 1.1.2 but not 1.1.3:
I noticed that this is breaking rustfmt (https://travis-ci.org/dtolnay/syn/jobs/513667990). Is there an easy fix on your end or would it be better for us to work around this downstream? Thanks!
The text was updated successfully, but these errors were encountered: