Make unwinding task-independent #12080
Comments
|
There are a two questions I can think of that the unwinding code needs to have answers to:
Perhaps these can be solved with thread-local globals? Right now we only have to worry about one thread local global which is quite convenient. Additionally, exposing a safe interface around this is going to be tough. I think that we can get by with: I remember there being issues around stack closures leaving captured things in an unusual state, but this doesn't seem much different to me than normal failure, so I may be forgetting why stack closures on try boundaries is a bad idea. |
|
Note that we now have a |
|
I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized. This issue has been moved to the RFCs repo: rust-lang/rfcs#632 |
Fixed ICE introduced in rust-lang#12004 Issue: in rust-lang/rust-clippy#12004, we emit a lint for `filter(Option::is_some)`. If the parent expression is a `.map` we don't emit that lint as there exists a more specialized lint for that. The ICE introduced in rust-lang/rust-clippy#12004 is a consequence of the assumption that a parent expression after a filter would be a method call with the filter call being the receiver. However, it is entirely possible to have a closure of the form ``` || { vec![Some(1), None].into_iter().filter(Option::is_some) } ``` The previous implementation looked at the parent expression; namely the closure, and tried to check the parameters by indexing [0] on an empty list. This commit is an overhaul of the lint with significantly more FP tests and checks. Impl details: 1. We verify that the filter method we are in is a proper trait method to avoid FPs. 2. We check that the parent expression is not a map by checking whether it exists; if is a trait method; and then a method call. 3. We check that we don't have comments in the span. 4. We verify that we are in an Iterator of Option and Result. 5. We check the contents of the filter. 1. For closures we peel it. If it is not a single expression, we don't lint. We then try again by checking the peeled expression. 2. For paths, we do a typecheck to avoid FPs for types that impl functions with the same names. 3. For calls, we verify the type, via the path, and that the param of the closure is the single argument to the call. 4. For method calls we verify that the receiver is the parameter of the closure. Since we handle single, non-block exprs, the parameter can't be shadowed, so no FP. This commit also adds additional FP tests. Fixes: rust-lang#12058 Adding `@xFrednet` as you've the most context for this as you reviewed it last time. `@rustbot` r? `@xFrednet` --- changelog: none (Will be backported and therefore don't effect stable)
For the sake of embedding applications it would be nice if Rust's unwinding implementation was not directly coupled to the task abstraction.
Right now unwinding is mostly just try/catch, but it also sets a flag on the task to indicate that the task is failing. It would be better if std could fulfill its unwinding obligations without involving the task.
The text was updated successfully, but these errors were encountered: