Merge pull request #380 from lqd/more_rfc_fixes

More rfc fixes

Author: lqd

src/2025h2/README.md

@@ -50,7 +50,7 @@ Rust's trait system is one of its most powerful features, but it has a number of
 * [Polonius](./polonius.md) will enable new borrowing patterns, and in particular [unblock "lending iterators"](https://github.com/rust-lang/rust/issues/92985). Over the last few goal periods we have identified an "alpha" vesion of polonius that addresses the most important cases while being relatively simple and optimizable. Our goal for 2025H2 is to implement this algorithm in a form that is ready for stabilization in 2026.
 * The [next gen trait solver](./next-solver.md) is a refactored trait solver that unblocks better support for numerous language features (implied bounds, negative impls, the list goes on) in addition to closing a number of existing bugs and unsoundnesses. Over the last few goal periods, the trait solver went from early prototype to being production use in coherence. The goal for 2025H2 is to prepare it for use throughout the compiler.
 * The work on [evolving trait hierarchies](./evolving-traits.md) will make it possible to refactor some parts of an existing trait out into a new supertrait so they can be used on their own. This unblocks a number of features where the existing trait is insufficiently general, in particular stabilizing support for custom receiver types, a prior project goal that wound up blocking on this refactoring.
-* The work to [expand Rust's `Sized` hierarchy](./scalable-vectors.md) will permit us to express types that are neither `Sized` nor `?Sized`, such as extern types (which have no size) or ARM's Scalable Vector Extensions (which have a size that is known at runtime, but not compilation time). This goal builds on [RFC #3729][] and [RFC #3838][], authored in previous project goal periods.
+* The work to [expand Rust's `Sized` hierarchy](./scalable-vectors.md) will permit us to express types that are neither `Sized` nor `?Sized`, such as extern types (which have no size) or Arm's Scalable Vector Extension (which have a size that is known at runtime, but not compilation time). This goal builds on [RFC #3729][] and [RFC #3838][], authored in previous project goal periods.
 * [In-place initialization](./in-place-initialization.md) allows creating structs and values that are tied to a particular place in memory. While useful directly for projects doing advanced C interop, it also unblocks expanding `dyn Trait` to support for `async fn` and `-> impl Trait` methods, as compiling such methods requires the ability for the callee to return a future whose size is not known to the caller.
 
 ### "Flexible, fast(er) Rust builds"

src/2025h2/autoreborrow-traits.md

@@ -1,4 +1,4 @@
-# Nightly support for Autoreborrow traits
+# Reborrow traits
 
 | Metadata            |                                                                                  |
 | :------------------ | -------------------------------------------------------------------------------- |
@@ -96,7 +96,7 @@ Users of `reborrow` crate and similar should be enabled to move to core solution
 | Standard reviews             | ![Team][] [compiler] | Trait-impl querying in rustc to replace `Pin<&mut T>` special case |
 | Do the work                  | @aapoalas            |                                                                    |
 
-### Design autoreborrow internals
+### Experiment with Reborrow trait design
 
 The basic idea of autoreborrowing is simple enough: when a reborrowable type is encountered at a coercion
 site, attempt a reborrow operation.
@@ -122,7 +122,7 @@ like `PhantomExclusive<'a>` and `PhantomShared<'b>` to discern the difference.
 | RFC decision         | ![Team][] [lang]                   |                                                                     |
 | RFC secondary review | ![Team][] [types]                  | request bandwidth from a second team, most features don't need this |
 
-### Implement non-recursive autoreborrowing
+### Seek feedback for an RFC based on experiment
 
 A basic autoreborrowing feature should not be too complicated: the `Pin<&mut T>` special-case in the
 compiler already exists and could probably be reimagined to rely on a `Reborrow` trait.