Replace txt with text

Author: varkor

src/appendix-stupid-stats.md

@@ -177,7 +177,7 @@ foo.rs` (assuming you have a Rust program called `foo.rs`. You can also pass any
 command line arguments that you would normally pass to rustc). When you run it
 you'll see output similar to
 
-```txt
+```text
 In crate: foo,
 
 Found 12 uses of `println!`;

src/high-level-overview.md

@@ -19,7 +19,7 @@ compilation improves, that may change.)
 
 The dependency structure of these crates is roughly a diamond:
 
-```txt
+```text
                   rustc_driver
                 /      |       \
               /        |         \

src/incrcomp-debugging.md

@@ -48,7 +48,7 @@ the graph. You can filter in three ways:
 To filter, use the `RUST_DEP_GRAPH_FILTER` environment variable, which should
 look like one of the following:
 
-```txt
+```text
 source_filter     // nodes originating from source_filter
 -> target_filter  // nodes that can reach target_filter
 source_filter -> target_filter // nodes in between source_filter and target_filter
@@ -58,14 +58,14 @@ source_filter -> target_filter // nodes in between source_filter and target_filt
 A node is considered to match a filter if all of those strings appear in its
 label. So, for example:
 
-```txt
+```text
 RUST_DEP_GRAPH_FILTER='-> TypeckTables'
 ```
 
 would select the predecessors of all `TypeckTables` nodes. Usually though you
 want the `TypeckTables` node for some particular fn, so you might write:
 
-```txt
+```text
 RUST_DEP_GRAPH_FILTER='-> TypeckTables & bar'
 ```
 
@@ -75,7 +75,7 @@ with `bar` in their name.
 Perhaps you are finding that when you change `foo` you need to re-type-check
 `bar`, but you don't think you should have to. In that case, you might do:
 
-```txt
+```text
 RUST_DEP_GRAPH_FILTER='Hir & foo -> TypeckTables & bar'
 ```
 
@@ -105,7 +105,7 @@ check of `bar` and you don't think there should be. You dump the
 dep-graph as described in the previous section and open `dep-graph.txt`
 to see something like:
 
-```txt
+```text
 Hir(foo) -> Collect(bar)
 Collect(bar) -> TypeckTables(bar)
 ```

src/method-lookup.md

@@ -99,7 +99,7 @@ So, let's continue our example. Imagine that we were calling a method
 that defines it with `&self` for the type `Rc<U>` as well as a method
 on the type `Box` that defines `Foo` but with `&mut self`. Then we
 might have two candidates:
-```txt
+```text
 &Rc<Box<[T; 3]>> from the impl of `Foo` for `Rc<U>` where `U=Box<T; 3]>
 &mut Box<[T; 3]>> from the inherent impl on `Box<U>` where `U=[T; 3]`
 ```

src/mir-passes.md

@@ -52,7 +52,7 @@ fn main() {
 The files have names like `rustc.main.000-000.CleanEndRegions.after.mir`. These
 names have a number of parts:
 
-```txt
+```text
 rustc.main.000-000.CleanEndRegions.after.mir
       ---- --- --- --------------- ----- either before or after
       |    |   |   name of the pass
@@ -159,7 +159,7 @@ ensuring that the reads have already happened (remember that
 [queries are memoized](./query.html), so executing a query twice
 simply loads from a cache the second time):
 
-```txt
+```text
 mir_const(D) --read-by--> mir_const_qualif(D)
      |                       ^
   stolen-by                  |

src/mir-regionck.md

@@ -122,7 +122,7 @@ stack, for example). But *how* do we reject it and *why*?
 When we type-check `main`, and in particular the call `bar(foo)`, we
 are going to wind up with a subtyping relationship like this one:
 
-```txt
+```text
 fn(&'static u32) <: for<'a> fn(&'a u32)
 ----------------    -------------------
 the type of `foo`   the type `bar` expects
@@ -137,7 +137,7 @@ regions" -- they represent, basically, "some unknown region".
 
 Once we've done that replacement, we have the following relation:
 
-```txt
+```text
 fn(&'static u32) <: fn(&'!1 u32)
 ```
 
@@ -151,7 +151,7 @@ subtypes, we check if their arguments have the desired relationship
 (fn arguments are [contravariant](./appendix-background.html#variance), so
 we swap the left and right here):
 
-```txt
+```text
 &'!1 u32 <: &'static u32
 ```
 
@@ -201,7 +201,7 @@ Here, the name `'b` is not part of the root universe. Instead, when we
 "enter" into this `for<'b>` (e.g., by skolemizing it), we will create
 a child universe of the root, let's call it U1:
 
-```txt
+```text
 U0 (root universe)
 │
 └─ U1 (child universe)
@@ -224,7 +224,7 @@ When we enter *this* type, we will again create a new universe, which
 we'll call `U2`. Its parent will be the root universe, and U1 will be
 its sibling:
 
-```txt
+```text
 U0 (root universe)
 │
 ├─ U1 (child universe)
@@ -263,7 +263,7 @@ children, that inference variable X would have to be in U0. And since
 X is in U0, it cannot name anything from U1 (or U2). This is perhaps easiest
 to see by using a kind of generic "logic" example:
 
-```txt
+```text
 exists<X> {
    forall<Y> { ... /* Y is in U1 ... */ }
    forall<Z> { ... /* Z is in U2 ... */ }
@@ -296,7 +296,7 @@ does not say region elements **will** appear.
 
 In the region inference engine, outlives constraints have the form:
 
-```txt
+```text
 V1: V2 @ P
 ```
 
@@ -346,7 +346,7 @@ for universal regions from the fn signature.)
 Put another way, the "universal regions" check can be considered to be
 checking constraints like:
 
-```txt
+```text
 {skol(1)}: V1
 ```
 
@@ -358,13 +358,13 @@ made to represent the `!1` region.
 OK, so far so good. Now let's walk through what would happen with our
 first example:
 
-```txt
+```text
 fn(&'static u32) <: fn(&'!1 u32) @ P  // this point P is not imp't here
 ```
 
 The region inference engine will create a region element domain like this:
 
-```txt
+```text
 { CFG; end('static); skol(1) }
     ---  ------------  ------- from the universe `!1`
     |    'static is always in scope
@@ -375,20 +375,20 @@ It will always create two universal variables, one representing
 `'static` and one representing `'!1`. Let's call them Vs and V1. They
 will have initial values like so:
 
-```txt
+```text
 Vs = { CFG; end('static) } // it is in U0, so can't name anything else
 V1 = { skol(1) }
 ```
 
 From the subtyping constraint above, we would have an outlives constraint like
 
-```txt
+```text
 '!1: 'static @ P
 ```
 
 To process this, we would grow the value of V1 to include all of Vs:
 
-```txt
+```text
 Vs = { CFG; end('static) }
 V1 = { CFG; end('static), skol(1) }
 ```
@@ -405,15 +405,15 @@ In this case, `V1` *did* grow too large -- it is not known to outlive
 
 What about this subtyping relationship?
 
-```txt
+```text
 for<'a> fn(&'a u32, &'a u32)
     <:
 for<'b, 'c> fn(&'b u32, &'c u32)
 ```
 
 Here we would skolemize the supertype, as before, yielding:
 
-```txt
+```text
 for<'a> fn(&'a u32, &'a u32)
     <:
 fn(&'!1 u32, &'!2 u32)
@@ -423,22 +423,22 @@ then we instantiate the variable on the left-hand side with an
 existential in universe U2, yielding the following (`?n` is a notation
 for an existential variable):
 
-```txt
+```text
 fn(&'?3 u32, &'?3 u32)
     <:
 fn(&'!1 u32, &'!2 u32)
 ```
 
 Then we break this down further:
 
-```txt
+```text
 &'!1 u32 <: &'?3 u32
 &'!2 u32 <: &'?3 u32
 ```
 
 and even further, yield up our region constraints:
 
-```txt
+```text
 '!1: '?3
 '!2: '?3
 ```
@@ -465,7 +465,7 @@ common lifetime of our arguments. -nmatsakis)
 Let's look at one last example. We'll extend the previous one to have
 a return type:
 
-```txt
+```text
 for<'a> fn(&'a u32, &'a u32) -> &'a u32
     <:
 for<'b, 'c> fn(&'b u32, &'c u32) -> &'b u32
@@ -478,23 +478,23 @@ first one. That is unsound. Let's see how it plays out.
 
 First, we skolemize the supertype:
 
-```txt
+```text
 for<'a> fn(&'a u32, &'a u32) -> &'a u32
     <:
 fn(&'!1 u32, &'!2 u32) -> &'!1 u32
 ```
 
 Then we instantiate the subtype with existentials (in U2):
 
-```txt
+```text
 fn(&'?3 u32, &'?3 u32) -> &'?3 u32
     <:
 fn(&'!1 u32, &'!2 u32) -> &'!1 u32
 ```
 
 And now we create the subtyping relationships:
 
-```txt
+```text
 &'!1 u32 <: &'?3 u32 // arg 1
 &'!2 u32 <: &'?3 u32 // arg 2
 &'?3 u32 <: &'!1 u32 // return type
@@ -503,15 +503,15 @@ And now we create the subtyping relationships:
 And finally the outlives relationships. Here, let V1, V2, and V3 be the
 variables we assign to `!1`, `!2`, and `?3` respectively:
 
-```txt
+```text
 V1: V3
 V2: V3
 V3: V1
 ```
 
 Those variables will have these initial values:
 
-```txt
+```text
 V1 in U1 = {skol(1)}
 V2 in U2 = {skol(2)}
 V3 in U2 = {}
@@ -520,14 +520,14 @@ V3 in U2 = {}
 Now because of the `V3: V1` constraint, we have to add `skol(1)` into `V3` (and
 indeed it is visible from `V3`), so we get:
 
-```txt
+```text
 V3 in U2 = {skol(1)}
 ```
 
 then we have this constraint `V2: V3`, so we wind up having to enlarge
 `V2` to include `skol(1)` (which it can also see):
 
-```txt
+```text
 V2 in U2 = {skol(1), skol(2)}
 ```
 

src/mir.md

@@ -159,7 +159,7 @@ _3 = &mut _1;
 
 Assignments in general have the form:
 
-```txt
+```text
 <Place> = <Rvalue>
 ```
 
@@ -169,7 +169,7 @@ value: in this case, the rvalue is a mutable borrow expression, which
 looks like `&mut <Place>`. So we can kind of define a grammar for
 rvalues like so:
 
-```txt
+```text
 <Rvalue>  = & (mut)? <Place>
           | <Operand> + <Operand>
           | <Operand> - <Operand>

src/tests/adding.md

@@ -298,7 +298,7 @@ default regex flavor provided by `regex` crate.
 The corresponding reference file will use the normalized output to test both
 32-bit and 64-bit platforms:
 
-```txt
+```text
 ...
    |
    = note: source type: fn() ($PTR bits)

src/traits-associated-types.md

@@ -51,7 +51,7 @@ In our logic, normalization is defined by a predicate
 impls. For example, the `impl` of `IntoIterator` for `Option<T>` that
 we saw above would be lowered to a program clause like so:
 
-```txt
+```text
 forall<T> {
     Normalize(<Option<T> as IntoIterator>::Item -> T)
 }
@@ -101,15 +101,15 @@ consider an associated type projection equal to another type?":
 We now introduce the `ProjectionEq` predicate to bring those two cases
 together. The `ProjectionEq` predicate looks like so:
 
-```txt
+```text
 ProjectionEq(<T as IntoIterator>::Item = U)
 ```
 
 and we will see that it can be proven *either* via normalization or
 skolemization. As part of lowering an associated type declaration from
 some trait, we create two program clauses for `ProjectionEq`:
 
-```txt
+```text
 forall<T, U> {
     ProjectionEq(<T as IntoIterator>::Item = U) :-
         Normalize(<T as IntoIterator>::Item -> U)
@@ -130,7 +130,7 @@ with unification. As described in the
 [type inference](./type-inference.html) section, unification is
 basically a procedure with a signature like this:
 
-```txt
+```text
 Unify(A, B) = Result<(Subgoals, RegionConstraints), NoSolution>
 ```