Rollup merge of #153172 - jdonszelmann:placeholder-comment, r=lcnr

Fix comment about placeholders

r? @lcnr

When this was introduced, briefly returned an `Option`, which is what the comment refers to.
https://github.com/rust-lang/rust/pull/86993/changes/a9f1e1c440ae20f0ea99f5e265f24094f1a613a5#diff-8d11697c196da9f44774488ae0bf353283e5c6466a6dd570d7818431b73d4a44R511

Before that this code would just panic, and in the commit right after fixing review comments it does so again:
https://github.com/rust-lang/rust/pull/86993/changes/cf001dc8894ae726de96f4db032f11c22f24c393#diff-8d11697c196da9f44774488ae0bf353283e5c6466a6dd570d7818431b73d4a44R560

That comment has been copied around for 5 years now despite not reflecting the behavior hehe

Second commit has some general typos I found

compiler/rustc_next_trait_solver/src/placeholder.rs

@@ -32,8 +32,10 @@ impl<'a, Infcx, I> BoundVarReplacer<'a, Infcx, I>
     Infcx: InferCtxtLike<Interner = I>,
     I: Interner,
 {
-    /// Returns `Some` if we *were* able to replace bound vars. If there are any bound vars that
-    /// use a binding level above `universe_indices.len()`, we fail.
+    /// Returns a type with all bound vars replaced by placeholders,
+    /// together with mappings from the new placeholders back to the original variable.
+    ///
+    /// Panics if there are any bound vars that use a binding level above `universe_indices.len()`.
     pub fn replace_bound_vars<T: TypeFoldable<I>>(
         infcx: &'a Infcx,
         universe_indices: &'a mut Vec<Option<ty::UniverseIndex>>,

compiler/rustc_next_trait_solver/src/solve/mod.rs

@@ -39,9 +39,9 @@
 ///
 /// We previously used  `cx.recursion_limit().0.checked_ilog2().unwrap_or(0)` for this.
 /// However, it feels unlikely that uncreasing the recursion limit by a power of two
-/// to get one more iteration is every useful or desirable. We now instead used a constant
+/// to get one more iteration is ever useful or desirable. We now instead used a constant
 /// here. If there ever ends up some use-cases where a bigger number of fixpoint iterations
-/// is required, we can add a new attribute for that or revert this to be dependant on the
+/// is required, we can add a new attribute for that or revert this to be dependent on the
 /// recursion limit again. However, this feels very unlikely.
 const FIXPOINT_STEP_LIMIT: usize = 8;