Goals and plan present some light background material on the borrow-checking code, NLL show the NLL scope computation (from a few weeks back), explain what needs to change to use the polonius model go over PR #113218 implementing that change Background The root of borrowck, do_mir_borrowck: a bunch of sequential steps Of interest today, some of the code path emitting errors: a. setting up some dataflow computations (we'll come back to flow_borrows) b. heavy lifting: done by visiting dataflow results

Goals present current polonius roadmap plan and ongoing work moving the polonius WG under t-types ? TL;DR This document lays out a tentative roadmap to get Polonius on stable by Rust 2024. It identifies some high-level milestones and summarizes the key goals. Background on polonius Like chalk, polonius refers to many things. It is a new formulation of the borrow check. It is also a specific project that implemented that analysis, based on datalog. Our current plan does not make use of that datalog-based implementation, and instead is focused on reimplementing polonius within rustc.

TL;DR This document lays out a roadmap to get Polonius on stable by Rust 2024. It identifies some high-level milestones and summarizes the key goals. Background on polonius Like chalk, polonius refers to many things. It is a new formulation of the borrow check. It is also a specific project that implemented that analysis, based on datalog. Our current plan does not make use of that datalog-based implementation, and instead is focused on reimplementing polonius within rustc. The motivating example for polonius is the so-called "Problem Case #3: conditional control flow across functions": here, returning a reference out of a function, from a conditional. fn get_default<'r, K: Hash + Eq + Copy, V: Default>( map: &'r mut HashMap<K, V>,

note to self: some python packages seem required for the crate to compile (cffi I think) 0. nightly vs msrv I'm currently testing on a recent nightly, compared to the crate's MSRV of 1.56. I'm mentioning this to reproduce some of my results (and nightlies are built differently compared to stable: more assertions/logging can slow nightlies down a bit, so that may skew the results), but that maybe there are optimizations applicable to older versions. Let me know if I should benchmark and profile on a different version of the compiler instead. (I'm using an epyc-7401P with the usual benchmarking settings, so it's 32 cores but you mentioned having 22 so I'll use that as the maximum) It seems cargo can't easily clean this cdylib project so that was interesting, maybe I'll open an issue about this. Not a big deal, but it makes benchmarking only the final crate harder; so I'll also usually benchmark with incremental compilation turned off explicitly (where touching the source files and rebuilding should only then build the final crate). 1. crates