misc changes

ci/sembr/src/main.rs

@@ -50,12 +50,12 @@ fn main() -> Result<()> {
         let old = fs::read_to_string(&path)?;
         let mut new = comply(&old);
         if cli.reflow_harder {
-            new = lengthen_lines(&new, cli.line_length_limit)
+            new = reformat(&new, cli.line_length_limit)
         }
         if new == old {
             compliant.push(path.clone());
         } else if cli.overwrite {
-            fs::write(&path, lengthen_lines(&new, cli.line_length_limit))?;
+            fs::write(&path, reformat(&new, cli.line_length_limit))?;
             made_compliant.push(path.clone());
         } else {
             not_compliant.push(path.clone());
@@ -133,7 +133,8 @@ fn comply(content: &str) -> String {
     new_content.join("\n") + "\n"
 }
 
-fn lengthen_lines(content: &str, limit: usize) -> String {
+// This reformats lines, so that changes of "fn comply" look more pretty
+fn reformat(content: &str, limit: usize) -> String {
     let content: Vec<_> = content.lines().map(std::borrow::ToOwned::to_owned).collect();
     let mut new_content = content.clone();
     let mut new_n = 0;
@@ -239,6 +240,8 @@ o? whatever
 r? @reviewer
  r? @reviewer
 ~? diagnostic
+
+the queries that we do, as well as the **query DAG**. The
 ";
     let expected = "
 # some. heading
@@ -272,12 +275,15 @@ whatever
 r? @reviewer
  r? @reviewer
 ~? diagnostic
+
+the queries that we do, as well as the **query DAG**.
+The
 ";
     assert_eq!(expected, comply(original));
 }
 
 #[test]
-fn test_lengthen_lines() {
+fn test_reformat_lines() {
     let original = "\
 do not split
 short sentences
@@ -308,6 +314,18 @@ html comment closing
  handle the
  indented well
 
+split on comma (filler), of
+current line
+
+  split on comma (filler), of
+  current line
+
+split on
+comma (filler), of next line
+
+  split on
+  comma (filler), of next line
+
 [a target]: https://example.com
 [another target]: https://example.com
 ";
@@ -339,10 +357,22 @@ html comment closing
 
  handle the indented well
 
+split on comma (filler),
+of current line
+
+  split on comma (filler),
+  of current line
+
+split on comma (filler),
+of next line
+
+  split on comma (filler),
+  of next line
+
 [a target]: https://example.com
 [another target]: https://example.com
 ";
-    assert_eq!(expected, lengthen_lines(original, 50));
+    assert_eq!(expected, reformat(original, 30));
 }
 
 #[test]
@@ -351,48 +381,3 @@ fn should_pass() {
     let original = "if you see `input isn't interesting! verify interesting-ness test`.";
     assert_eq!(original, comply(original));
 }
-
-#[test]
-fn split_on_comma_of_current_line() {
-    let original = "
-Each derived value has a dependency, on other values, which could themselves be either base or
-derived.
-
-  Each derived value has a dependency, on other values, which could themselves be either base or
-  derived.
-";
-    let expected = "
-Each derived value has a dependency, on other values,
-which could themselves be either base or derived.
-
-  Each derived value has a dependency, on other values,
-  which could themselves be either base or derived.
-";
-    assert_eq!(expected, lengthen_lines(original, 100))
-}
-
-#[test]
-fn split_on_comma_of_next_line() {
-    let original = "
-Because of canonicalization of regions and
-inference variables, encountering a cycle doesn't mean that we would get an infinite proof tree.
-
-  Because of canonicalization of regions and
-  inference variables, encountering a cycle doesn't mean that we would get an infinite proof tree.
-";
-    let expected = "
-Because of canonicalization of regions and inference variables,
-encountering a cycle doesn't mean that we would get an infinite proof tree.
-
-  Because of canonicalization of regions and inference variables,
-  encountering a cycle doesn't mean that we would get an infinite proof tree.
-";
-    assert_eq!(expected, lengthen_lines(original, 100))
-}
-
-#[test]
-fn should_split() {
-    let original = "the queries that we do, as well as the **query DAG**. The";
-    let expected = "the queries that we do, as well as the **query DAG**.\nThe\n";
-    assert_eq!(expected, comply(original));
-}

src/building/bootstrapping/what-bootstrapping-does.md

@@ -15,8 +15,8 @@ See [bootstrap/README.md][bootstrap-internals] to read about bootstrap internals
 - Stage 3: the same-result test
 
 Compiling `rustc` is done in stages.
-Here's a diagram, adapted from Jynn
-Nelson's [talk on bootstrapping][rustconf22-talk] at RustConf 2022,
+Here's a diagram,
+adapted from Jynn Nelson's [talk on bootstrapping][rustconf22-talk] at RustConf 2022,
 with detailed explanations below.
 
 The `A`, `B`, `C`, and `D` show the ordering of the stages of bootstrapping.
@@ -298,12 +298,12 @@ but `lib` will never be part of the search path.
 
 #### `-Z force-unstable-if-unmarked`
 
-Since `lib/rustlib/` is part of the search path we have to be careful about
-which crates are included in it.
-In particular, all crates except for the
-standard library are built with the flag `-Z force-unstable-if-unmarked`,
-which means that you have to use `#![feature(rustc_private)]` in order to load it (as
-opposed to the standard library, which is always available).
+Since `lib/rustlib/` is part of the search path,
+we have to be careful about which crates are included in it.
+In particular, all crates, except for the standard library,
+are built with the flag `-Z force-unstable-if-unmarked`,
+meaning that you have to use `#![feature(rustc_private)]` in order to load it
+(as opposed to the standard library, which is always available).
 
 The `-Z force-unstable-if-unmarked` flag has a variety of purposes to help
 enforce that the correct crates are marked as `unstable`.

src/const-generics.md

@@ -27,7 +27,8 @@ struct Foo<const N: usize>;
 type Alias = [u8; 1 + 1];
 ```
 
-In this example we have a const argument of `1 + 1` (the array length) which is represented as an *anon const*. The desugaring would look something like:
+In this example we have a const argument of `1 + 1` (the array length) which is represented as an *anon const*.
+The desugaring would look something like:
 ```rust
 struct Foo<const N: usize>;
 
@@ -81,9 +82,11 @@ type Alias = [u8; ANON];
 When we go through HIR ty lowering for the array type in `Alias`, we will lower the array length too, and feed `type_of(ANON) -> usize`.
 This will effectively set the type of the `ANON` const item during some later part of the compiler rather than when constructing the HIR.
 
-After all of this desugaring has taken place the final representation in the type system (ie as a `ty::Const`) is a `ConstKind::Alias` with the `DefId` of the `AnonConst`. This is equivalent to how we would representa a usage of an actual const item if we were to represent them without going through an anon const (e.g. when `gca_min_const_items` is enabled).
+After all of this desugaring has taken place the final representation in the type system (ie as a `ty::Const`) is a `ConstKind::Alias` with the `DefId` of the `AnonConst`.
+This is equivalent to how we would represent a usage of an actual const item if we were to represent them without going through an anon const (e.g. when `gca_generic_const_args` is enabled).
 
-This allows the representation for const "aliases" to be the same as the representation of `TyKind::Alias`. Having a proper HIR body also allows for a *lot* of code re-use, e.g. we can reuse HIR typechecking and all of the lowering steps to MIR where we can then reuse const eval.
+This allows the representation for const "aliases" to be the same as the representation of `TyKind::Alias`.
+Having a proper HIR body also allows for a *lot* of code re-use, e.g. we can reuse HIR typechecking and all of the lowering steps to MIR where we can then reuse const eval.
 
 ### Enforcing lack of generic parameters
 

src/debuginfo/llvm-codegen.md

@@ -1,13 +1,13 @@
 # LLVM codegen
 
-When Rust calls an LLVM `DIBuilder` function, LLVM translates the given information to a
-["debug record"][dbg_record] that is format-agnostic.
+When Rust calls an LLVM `DIBuilder` function,
+LLVM translates the given information to a ["debug record"][dbg_record] that is format-agnostic.
 These records can be inspected in the LLVM-IR.
 
 [dbg_record]: https://llvm.org/docs/SourceLevelDebugging.html#debug-records
 
-It is important to note that tags within the debug records are **always stored as DWARF tags**. If
-the target calls for PDB debug info, during codegen the debug records will then be passed through
+It is important to note that tags within the debug records are **always stored as DWARF tags**.
+If the target calls for PDB debug info, during codegen, the debug records will then be passed through
 [a module that translates the DWARF tags to their CodeView counterparts][cv].
 
 [cv]:https://github.com/llvm/llvm-project/blob/main/llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp