mirror of
https://github.com/rust-lang/rust.git
synced 2025-02-10 05:53:10 +00:00
3d10c64b26
Introduce drop range tracking to generator interior analysis This PR addresses cases such as this one from #57478: ```rust struct Foo; impl !Send for Foo {} let _: impl Send = || { let guard = Foo; drop(guard); yield; }; ``` Previously, the `generator_interior` pass would unnecessarily include the type `Foo` in the generator because it was not aware of the behavior of `drop`. We fix this issue by introducing a drop range analysis that finds portions of the code where a value is guaranteed to be dropped. If a value is dropped at all suspend points, then it is no longer included in the generator type. Note that we are using "dropped" in a generic sense to include any case in which a value has been moved. That is, we do not only look at calls to the `drop` function. There are several phases to the drop tracking algorithm, and we'll go into more detail below. 1. Use `ExprUseVisitor` to find values that are consumed and borrowed. 2. `DropRangeVisitor` uses consume and borrow information to gather drop and reinitialization events, as well as build a control flow graph. 3. We then propagate drop and reinitialization information through the CFG until we reach a fix point (see `DropRanges::propagate_to_fixpoint`). 4. When recording a type (see `InteriorVisitor::record`), we check the computed drop ranges to see if that value is definitely dropped at the suspend point. If so, we skip including it in the type. ## 1. Use `ExprUseVisitor` to find values that are consumed and borrowed. We use `ExprUseVisitor` to identify the places where values are consumed. We track both the `hir_id` of the value, and the `hir_id` of the expression that consumes it. For example, in the expression `[Foo]`, the `Foo` is consumed by the array expression, so after the array expression we can consider the `Foo` temporary to be dropped. In this process, we also collect values that are borrowed. The reason is that the MIR transform for generators conservatively assumes anything borrowed is live across a suspend point (see `rustc_mir_transform::generator::locals_live_across_suspend_points`). We match this behavior here as well. ## 2. Gather drop events, reinitialization events, and control flow graph After finding the values of interest, we perform a post-order traversal over the HIR tree to find the points where these values are dropped or reinitialized. We use the post-order index of each event because this is how the existing generator interior analysis refers to the position of suspend points and the scopes of variables. During this traversal, we also record branching and merging information to handle control flow constructs such as `if`, `match`, and `loop`. This is necessary because values may be dropped along some control flow paths but not others. ## 3. Iterate to fixed point The previous pass found the interesting events and locations, but now we need to find the actual ranges where things are dropped. Upon entry, we have a list of nodes ordered by their position in the post-order traversal. Each node has a set of successors. For each node we additionally keep a bitfield with one bit per potentially consumed value. The bit is set if we the value is dropped along all paths entering this node. To compute the drop information, we first reverse the successor edges to find each node's predecessors. Then we iterate through each node, and for each node we set its dropped value bitfield to the intersection of all incoming dropped value bitfields. If any bitfield for any node changes, we re-run the propagation loop again. ## 4. Ignore dropped values across suspend points At this point we have a data structure where we can ask whether a value is guaranteed to be dropped at any post order index for the HIR tree. We use this information in `InteriorVisitor` to check whether a value in question is dropped at a particular suspend point. If it is, we do not include that value's type in the generator type. Note that we had to augment the region scope tree to include all yields in scope, rather than just the last one as we did before. r? `@nikomatsakis` |
||
|---|---|---|
| .. | ||
| rustc | ||
| rustc_apfloat | ||
| rustc_arena | ||
| rustc_ast | ||
| rustc_ast_lowering | ||
| rustc_ast_passes | ||
| rustc_ast_pretty | ||
| rustc_attr | ||
| rustc_borrowck | ||
| rustc_builtin_macros | ||
| rustc_codegen_cranelift | ||
| rustc_codegen_gcc | ||
| rustc_codegen_llvm | ||
| rustc_codegen_ssa | ||
| rustc_const_eval | ||
| rustc_data_structures | ||
| rustc_driver | ||
| rustc_error_codes | ||
| rustc_errors | ||
| rustc_expand | ||
| rustc_feature | ||
| rustc_fs_util | ||
| rustc_graphviz | ||
| rustc_hir | ||
| rustc_hir_pretty | ||
| rustc_incremental | ||
| rustc_index | ||
| rustc_infer | ||
| rustc_interface | ||
| rustc_lexer | ||
| rustc_lint | ||
| rustc_lint_defs | ||
| rustc_llvm | ||
| rustc_log | ||
| rustc_macros | ||
| rustc_metadata | ||
| rustc_middle | ||
| rustc_mir_build | ||
| rustc_mir_dataflow | ||
| rustc_mir_transform | ||
| rustc_monomorphize | ||
| rustc_parse | ||
| rustc_parse_format | ||
| rustc_passes | ||
| rustc_plugin_impl | ||
| rustc_privacy | ||
| rustc_query_impl | ||
| rustc_query_system | ||
| rustc_resolve | ||
| rustc_save_analysis | ||
| rustc_serialize | ||
| rustc_session | ||
| rustc_span | ||
| rustc_symbol_mangling | ||
| rustc_target | ||
| rustc_trait_selection | ||
| rustc_traits | ||
| rustc_ty_utils | ||
| rustc_type_ir | ||
| rustc_typeck | ||