Expand polonius summary

mdbook-goals/src/markwaydown.rs

@@ -47,7 +47,7 @@ pub fn parse(path: &Path) -> anyhow::Result<Vec<Section>> {
                 if let Some(table) = &mut open_table {
                     if row.len() > table.header.len() {
                         return Err(anyhow::anyhow!(
-                            "{}:{}: too many columns in table, expeceted no more than {}",
+                            "{}:{}: too many columns in table, expected no more than {}",
                             path.display(),
                             line_num,
                             table.header.len()
@@ -71,7 +71,7 @@ pub fn parse(path: &Path) -> anyhow::Result<Vec<Section>> {
                 if let Some(table) = &open_table {
                     if table.header.len() != len {
                         return Err(anyhow::anyhow!(
-                            "{}:{}: too many columns in table, expeceted no more than {}",
+                            "{}:{}: too many columns in table, expected no more than {}",
                             path.display(),
                             line_num,
                             table.header.len()

src/2024h2/Polonius.md

@@ -8,12 +8,16 @@
 
 ## Summary
 
-Improve the Nightly support for [Polonius][pc3], next generation borrow checking, so that it can scale
+Implement a native rustc version of the [Polonius][pc3] next generation borrow checking algorithm, that would scale better than the previous [datalog] implementation.
+
+[datalog]: https://github.com/rust-lang/polonius
 
 ## Motivation
 
 Polonius is an improved version of the borrow checker that [resolves common limitations of the borrow checker][pc3] and which is needed to support future patterns such as "lending iterators" (see [#92985]). Its model also prepares us for further improvements in the future.
 
+Some support exists on nightly, but this [older prototype][datalog] has no path to stabilization due to scalability issues. We need an improved architecture and implementation to fix these issues.
+
 [pc3]: https://blog.rust-lang.org/inside-rust/2023/10/06/polonius-update.html#background-on-polonius
 
 ### The status quo

src/2024h2/async.md

@@ -37,7 +37,7 @@ Despite async Rust's popularity, using async I/O makes Rust significantly harder
   * [ ] [drop](https://rust-lang.github.io/wg-async/vision/submitted_stories/status_quo/alan_finds_database_drops_hard.html)
   In many cases there are workarounds or crates that can close the gap, but users have to learn about and find those crates.
 * Common async idioms have "sharp edges" that lead to unexpected failures, forcing users to manage [cancellation safety](https://rust-lang.github.io/wg-async/vision/submitted_stories/status_quo/barbara_gets_burned_by_select.html), subtle [deadlocks](https://rust-lang.github.io/wg-async/vision/submitted_stories/status_quo/aws_engineer/solving_a_deadlock.html) and other failure modes for [buffered streams](https://rust-lang.github.io/wg-async/vision/submitted_stories/status_quo/barbara_battles_buffered_streams.html). See also tmandry's blog post on [Making async Rust reliable](https://tmandry.gitlab.io/blog/posts/making-async-reliable/)).
-* Using async today requires users to select a runtime which provides many of the core primitives. Selecting a runtime as a user [can be stressful](https://rust-lang.github.io/wg-async/vision/submitted_stories/status_quo/barbara_makes_their_first_steps_into_async.html#the-wrong-time-for-big-decisions), as the [decision once made is hard to reverse](https://rust-lang.github.io/wg-async/vision/submitted_stories/status_quo/barbara_wishes_for_easy_runtime_switch.html). Moreover, in an attempt to avoid "picking favories", the project has not endorsed a particular runtime, making it [harder to write new user documentation](https://rust-lang.github.io/wg-async/vision/submitted_stories/status_quo/niklaus_wants_to_share_knowledge.html). Libaries meanwhile [cannot easily be made interoperable across runtimes](https://rust-lang.github.io/wg-async/vision/submitted_stories/status_quo/barbara_writes_a_runtime_agnostic_lib.html) and so are often written against the API of a particular runtime; even when libraries can be retargeted, it is difficult to do things like run their test suites to test compatibility. [Mixing and matching libraries can cause surprising failures.](https://rust-lang.github.io/wg-async/vision/submitted_stories/status_quo/alan_started_trusting_the_rust_compiler_but_then_async.html)
+* Using async today requires users to select a runtime which provides many of the core primitives. Selecting a runtime as a user [can be stressful](https://rust-lang.github.io/wg-async/vision/submitted_stories/status_quo/barbara_makes_their_first_steps_into_async.html#the-wrong-time-for-big-decisions), as the [decision once made is hard to reverse](https://rust-lang.github.io/wg-async/vision/submitted_stories/status_quo/barbara_wishes_for_easy_runtime_switch.html). Moreover, in an attempt to avoid "picking favories", the project has not endorsed a particular runtime, making it [harder to write new user documentation](https://rust-lang.github.io/wg-async/vision/submitted_stories/status_quo/niklaus_wants_to_share_knowledge.html). Libraries meanwhile [cannot easily be made interoperable across runtimes](https://rust-lang.github.io/wg-async/vision/submitted_stories/status_quo/barbara_writes_a_runtime_agnostic_lib.html) and so are often written against the API of a particular runtime; even when libraries can be retargeted, it is difficult to do things like run their test suites to test compatibility. [Mixing and matching libraries can cause surprising failures.](https://rust-lang.github.io/wg-async/vision/submitted_stories/status_quo/alan_started_trusting_the_rust_compiler_but_then_async.html)
 
 [afitblog]: https://blog.rust-lang.org/2023/12/21/async-fn-rpit-in-traits.html
 [embassy]: https://github.com/embassy-rs/embassy
@@ -79,7 +79,7 @@ Despite its limitations, the async working group serves several important functi
 
 * It provides a forum for discussion around async-related topics, including the `#async-wg` zulip stream as well as regular sync meetings. These forums don't necessarily get participation by the full set of voices that we would like, however.
 * It owns async-related repositories, such as the sources for the [async Rust book](https://rust-lang.github.io/async-book/) (in dire need of improvement), [arewewebyet](https://www.arewewebyet.org/), and the [futures-rs](https://rust-lang.github.io/futures-rs/) crate. Maintenance of these sites has varied though and often been done by a few individuals acting largely independently.
-* It advises the more general teams (typically [lang][] and [libs-api][]) on async-related matters. The authoring of the (mildly dated) [async vision doc](https://rust-lang.github.io/wg-async/vision/) took place under the auspices of the working group, for example. However, the group lacks decision making power and doesn't have a strong incentive to coallesce behind a shared vision, so it remains more a "set of individual voices" that does not provide the general purpose teams with clear guidance.
+* It advises the more general teams (typically [lang][] and [libs-api][]) on async-related matters. The authoring of the (mildly dated) [async vision doc](https://rust-lang.github.io/wg-async/vision/) took place under the auspices of the working group, for example. However, the group lacks decision making power and doesn't have a strong incentive to coalesce behind a shared vision, so it remains more a "set of individual voices" that does not provide the general purpose teams with clear guidance.
 
 We plan to propose one or more permanent teams to meet these same set of needs. The expectation is that these will be subteams under the [lang] and [libs] top-level teams.
 
@@ -168,7 +168,7 @@ Our eventual goal is to provide Rust users building on async with
 
 * **Uphold sync Rust's bar for reliability.** Sync Rust famously delivers on the general feeling of "if it compiles, it works" -- async Rust should do the same.
 * **We lay the foundations for a thriving ecosystem.** The role of the Rust org is to develop the rudiments that support an interoperable and thriving async crates.io ecosystem.
-* **When in doubt, zero-cost is our compass.** Many of Rust's biggest users are choosing it becase they know it can deliver the same performnace (or better) than C. If we adopt abstractions that add overhead, we are compromising that core strength. As we build out our designs, we ensure that they don't introduce an "abstraction tax" for using them.
+* **When in doubt, zero-cost is our compass.** Many of Rust's biggest users are choosing it because they know it can deliver the same performance (or better) than C. If we adopt abstractions that add overhead, we are compromising that core strength. As we build out our designs, we ensure that they don't introduce an "abstraction tax" for using them.
 * **From embedded to GUI to the cloud.** Async Rust covers a wide variety of use cases and we aim to make designs that can span those differing constraints with ease.
 * **Consistent, incremental progress.** People are building async Rust systems *today* -- we need to ship incremental improvements while also steering towards the overall outcome we want.
 

src/2024h2/cargo-script.md

@@ -8,7 +8,7 @@
 
 ## Summary
 
-Stablize support for "cargo script", the ability to have a single file that contains both Rust code and a `Cargo.toml`.
+Stabilize support for "cargo script", the ability to have a single file that contains both Rust code and a `Cargo.toml`.
 
 ## Motivation
 

src/2024h2/cargo-semver-checks.md

@@ -92,7 +92,7 @@ pub fn example(value: i64) {}
 ```
 Analogous breaking changes to function return values, struct fields, and associated types would also be missed by `cargo-semver-checks` today.
 
-The main difficulty here lies with the expressiveness of the Rust type system. For example, none of the follwing changes are breaking:
+The main difficulty here lies with the expressiveness of the Rust type system. For example, none of the following changes are breaking:
 ```rust
 // previous release:
 pub fn example(value: String) {}
@@ -128,7 +128,7 @@ To accomplish this, `cargo-semver-checks` needs the ability to express more kind
 
 **Owner:** @obi1kenobi, as maintainer of `cargo-semver-checks`
 
-I (@obi1kenobi) will be working on this effort. The only other resource request would be occassional discussions and moral support from the [cargo] team, of which I already have the privilege as maintainer of a popular cargo plugin.
+I (@obi1kenobi) will be working on this effort. The only other resource request would be occasional discussions and moral support from the [cargo] team, of which I already have the privilege as maintainer of a popular cargo plugin.
 
 | Subgoal                                          | Owner(s) or team(s)     | Notes |
 | ------------------------------------------------ | ----------------------- | ----- |

src/2024h2/ergonomic-rc.md

@@ -25,7 +25,7 @@ let state = Arc::new(some_state);
 tokio::spawn(async move { /* code using `state` */ });
 ```
 
-This scenario can be quite confusing for new users (see e.g. this [2014 talk at StrangeLoop](https://youtu.be/U3upi-y2pCk?si=kFEhRB_O_wdMKysC&t=807) where an experiened developer describes how confusing they found this to be). Many users settle on a workaround where they first clone the variable into a fresh local with a new name, such as:
+This scenario can be quite confusing for new users (see e.g. this [2014 talk at StrangeLoop](https://youtu.be/U3upi-y2pCk?si=kFEhRB_O_wdMKysC&t=807) where an experienced developer describes how confusing they found this to be). Many users settle on a workaround where they first clone the variable into a fresh local with a new name, such as:
 
 ```rust
 let state = Arc::new(some_state);
@@ -53,7 +53,7 @@ Whichever pattern users adopt, explicit clones of reference counted values leads
 
 #### Impact on new users and high-level domains
 
-The impact of this kind of friction can be severe. While experinced users have learned the workaround and consider this to be a papercut, new users can find this kind of change bewildering and a total blocker. The impact is also particularly severe on projects attempting to use Rust in domains traditionally considered "high-level" (e.g., app/game/web development, data science, scientific computing). Rust's strengths have made it a popular choice for building underlying frameworks and libraries that perform reliably and with high performance. However, thanks in large part to these kind of smaller, papercut issues, it is not a great choice for **consumption** of these libraries
+The impact of this kind of friction can be severe. While experienced users have learned the workaround and consider this to be a papercut, new users can find this kind of change bewildering and a total blocker. The impact is also particularly severe on projects attempting to use Rust in domains traditionally considered "high-level" (e.g., app/game/web development, data science, scientific computing). Rust's strengths have made it a popular choice for building underlying frameworks and libraries that perform reliably and with high performance. However, thanks in large part to these kind of smaller, papercut issues, it is not a great choice for **consumption** of these libraries
 
 Users in higher-level domains are accustomed to the ergonomics of Python or TypeScript, and hence ergonomic friction can make Rust a non-starter. Those users that stick with Rust long enough to learn the workarounds, however, often find significant value in its emphasis on reliability and long-term maintenance (not to mention performance). Small changes like avoiding explicit clones for reference-counted data can both help to make Rust more appealing in these domains **and** help Rust in other domains where it is already widespead. 
 

src/2024h2/min_generic_const_arguments.md

@@ -24,7 +24,7 @@ It is possible to use generic parameters with const generics by using `feature(g
 
 ### The next six months
 
-We have a design for `min_generic_const_args` approach in mind but we want to validate it through implementation as const generics has a history of unforseen issues showing up during implementation. Therefore we will pursue a prototype implementation in 2024.
+We have a design for `min_generic_const_args` approach in mind but we want to validate it through implementation as const generics has a history of unforeseen issues showing up during implementation. Therefore we will pursue a prototype implementation in 2024.
 
 As a stretch goal, we will attempt to review the design with the lang team in the form of a design meeting or RFC. Doing so will likely also involve authoring a design retrospective for `generic_const_exprs` in order to communicate why that design did not work out and why the constraints imposed by `min_generic_const_args` makes sense.
 

src/2024h2/next-solver.md

@@ -17,7 +17,7 @@ In the next 6 months we plan to extend the next-generation trait solver as follo
 
 ## Motivation
 
-The existing trait system implementation has many bugs, inefficiencies and rough corners which require major changes to its implementation. To fix existing unsound issues, accomodate future improvements, and to improve compile times, we are reimplementing the core trait solver to replace the existing implementations of `select` and `fulfill`.
+The existing trait system implementation has many bugs, inefficiencies and rough corners which require major changes to its implementation. To fix existing unsound issues, accommodate future improvements, and to improve compile times, we are reimplementing the core trait solver to replace the existing implementations of `select` and `fulfill`.
 
 ### The status quo
 

src/2024h2/user-wide-cache.md

@@ -55,7 +55,7 @@ Add support for user-wide intermediate artifact caching
   - If hash key is present, use the artifacts straight from the cache, otherwise build it and put it in the cache
   - Limit this immutable packages ("non-local" in cargo terms, like Registry, git dependencies)
   - Limit this to idempotent packages (can't depend on proc-macro, can't have a `build.rs`)
-  - Evaluate risks and deterine how we will stabilize this (e.g. unstable to stable, opt-in to opt-out to only on)
+  - Evaluate risks and determine how we will stabilize this (e.g. unstable to stable, opt-in to opt-out to only on)
 - Track intermediate build artifacts for garbage collection
 - Explore
   - Idempotence opt-ins for `build.rs` or proc-macros until sandboxing solutions can determine the level of idempotence.