bors 68c8fdaac0 Auto merge of #108293 - Jarcho:mut_analyses, r=eholk ... Take MIR dataflow analyses by mutable reference The main motivation here is any analysis requiring dynamically sized scratch memory to work. One concrete example would be pointer target tracking, where tracking the results of a dereference can result in multiple possible targets. This leads to processing multi-level dereferences requiring the ability to handle a changing number of potential targets per step. A (simplified) function for this would be `fn apply_deref(potential_targets: &mut Vec<Target>)` which would use the scratch space contained in the analysis to send arguments and receive the results. The alternative to this would be to wrap everything in a `RefCell`, which is what `MaybeRequiresStorage` currently does. This comes with a small perf cost and loses the compiler's guarantee that we don't try to take multiple borrows at the same time. For the implementation: * `AnalysisResults` is an unfortunate requirement to avoid an unconstrained type parameter error. * `CloneAnalysis` could just be `Clone` instead, but that would result in more work than is required to have multiple cursors over the same result set. * `ResultsVisitor` now takes the results type on in each function as there's no other way to have access to the analysis without cloning it. This could use an associated type rather than a type parameter, but the current approach makes it easier to not care about the type when it's not necessary. * `MaybeRequiresStorage` now no longer uses a `RefCell`, but the graphviz formatter now does. It could be removed, but that would require even more changes and doesn't really seem necessary.		2023-06-08 23:58:44 +00:00
..
src	Auto merge of #108293 - Jarcho:mut_analyses, r=eholk	2023-06-08 23:58:44 +00:00
Cargo.toml	Add rustc_fluent_macro to decouple fluent from rustc_macros	2023-04-18 18:56:22 +00:00
messages.ftl	Use translatable diagnostics in rustc_const_eval	2023-06-01 14:45:18 +00:00