fix all the not-en-dashes

Author: mark-i-m

README.md

@@ -18,8 +18,8 @@ Once it gets more complete, the plan is probably to move it into the
 If you'd like to help finish the guide, we'd love to have you! The
 main tracking issue for the guide
 [can be found here](https://github.com/rust-lang-nursery/rustc-guide/issues/6). From
-there, you can find a list of all the planned chapters and subsections
--- if you think something is missing, please open an issue about it!
+there, you can find a list of all the planned chapters and subsections.
+If you think something is missing, please open an issue about it!
 Otherwise, find a chapter that sounds interesting to you and then go
 to its associated issue. There should be a list of things to do.
 

src/appendix/background.md

@@ -15,7 +15,7 @@ exposes the underlying control flow in a very clear way.
 
 A control-flow graph is structured as a set of **basic blocks**
 connected by edges. The key idea of a basic block is that it is a set
-of statements that execute "together" -- that is, whenever you branch
+of statements that execute "together" – that is, whenever you branch
 to a basic block, you start at the first statement and then execute
 all the remainder. Only at the end of the block is there the
 possibility of branching to more than one place (in MIR, we call that
@@ -119,7 +119,7 @@ variables, since that's the thing we're most familiar with.
 So there you have it: a variable "appears free" in some
 expression/statement/whatever if it refers to something defined
 outside of that expressions/statement/whatever. Equivalently, we can
-then refer to the "free variables" of an expression -- which is just
+then refer to the "free variables" of an expression – which is just
 the set of variables that "appear free".
 
 So what does this have to do with regions? Well, we can apply the

src/compiletest.md

@@ -16,7 +16,7 @@ expect, and more.  If you are unfamiliar with the compiler testing framework,
 see [this chapter](./tests/intro.html) for additional background.
 
 The tests themselves are typically (but not always) organized into
-"suites"--for example, `run-pass`, a folder representing tests that should
+"suites" – for example, `run-pass`, a folder representing tests that should
 succeed, `run-fail`, a folder holding tests that should compile successfully,
 but return a failure (non-zero status), `compile-fail`, a folder holding tests
 that should fail to compile, and many more.  The various suites are defined in

src/conventions.md

@@ -44,8 +44,8 @@ current year if you like, but you don't have to.
 Lines should be at most 100 characters. It's even better if you can
 keep things to 80.
 
-**Ignoring the line length limit.** Sometimes -- in particular for
-tests -- it can be necessary to exempt yourself from this limit. In
+**Ignoring the line length limit.** Sometimes – in particular for
+tests – it can be necessary to exempt yourself from this limit. In
 that case, you can add a comment towards the top of the file (after
 the copyright notice) like so:
 
@@ -141,7 +141,7 @@ command like `git rebase -i rust-lang/master` (presuming you use the
 name `rust-lang` for your remote).
 
 **Individual commits do not have to build (but it's nice).** We do not
-require that every intermediate commit successfully builds -- we only
+require that every intermediate commit successfully builds – we only
 expect to be able to bisect at a PR level. However, if you *can* make
 individual commits build, that is always helpful.
 

src/incrcomp-debugging.md

@@ -90,7 +90,7 @@ path that should not exist, but you will not be quite sure how it came
 to be. **When the compiler is built with debug assertions,** it can
 help you track that down. Simply set the `RUST_FORBID_DEP_GRAPH_EDGE`
 environment variable to a filter. Every edge created in the dep-graph
-will be tested against that filter -- if it matches, a `bug!` is
+will be tested against that filter – if it matches, a `bug!` is
 reported, so you can easily see the backtrace (`RUST_BACKTRACE=1`).
 
 The syntax for these filters is the same as described in the previous

src/mir/borrowck.md

@@ -1,6 +1,6 @@
 # MIR borrow check
 
-The borrow check is Rust's "secret sauce" -- it is tasked with
+The borrow check is Rust's "secret sauce" – it is tasked with
 enforcing a number of properties:
 
 - That all variables are initialized before they are used.

src/mir/index.md

@@ -3,7 +3,7 @@
 MIR is Rust's _Mid-level Intermediate Representation_. It is
 constructed from [HIR](./hir.html). MIR was introduced in
 [RFC 1211]. It is a radically simplified form of Rust that is used for
-certain flow-sensitive safety checks -- notably the borrow checker! --
+certain flow-sensitive safety checks – notably the borrow checker! –
 and also for optimization and code generation.
 
 If you'd like a very high-level introduction to MIR, as well as some
@@ -122,7 +122,7 @@ StorageLive(_1);
 ```
 
 This statement indicates that the variable `_1` is "live", meaning
-that it may be used later -- this will persist until we encounter a
+that it may be used later – this will persist until we encounter a
 `StorageDead(_1)` statement, which indicates that the variable `_1` is
 done being used. These "storage statements" are used by LLVM to
 allocate stack space.
@@ -134,7 +134,7 @@ _1 = const <std::vec::Vec<T>>::new() -> bb2;
 ```
 
 Terminators are different from statements because they can have more
-than one successor -- that is, control may flow to different
+than one successor – that is, control may flow to different
 places. Function calls like the call to `Vec::new` are always
 terminators because of the possibility of unwinding, although in the
 case of `Vec::new` we are able to see that indeed unwinding is not
@@ -163,7 +163,7 @@ Assignments in general have the form:
 <Place> = <Rvalue>
 ```
 
-A place is an expression like `_3`, `_3.f` or `*_3` -- it denotes a
+A place is an expression like `_3`, `_3.f` or `*_3` – it denotes a
 location in memory.  An **Rvalue** is an expression that creates a
 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
@@ -180,7 +180,7 @@ rvalues like so:
           | move Place
 ```
 
-As you can see from this grammar, rvalues cannot be nested -- they can
+As you can see from this grammar, rvalues cannot be nested – they can
 only reference places and constants. Moreover, when you use a place,
 we indicate whether we are **copying it** (which requires that the
 place have a type `T` where `T: Copy`) or **moving it** (which works

src/mir/passes.md

@@ -100,8 +100,8 @@ that appeared within the `main` function.)
 
 ### Implementing and registering a pass
 
-A `MirPass` is some bit of code that processes the MIR, typically --
-but not always -- transforming it along the way somehow. For example,
+A `MirPass` is some bit of code that processes the MIR, typically –
+but not always – transforming it along the way somehow. For example,
 it might perform an optimization. The `MirPass` trait itself is found
 in in [the `rustc_mir::transform` module][mirtransform], and it
 basically consists of one method, `run_pass`, that simply gets an
@@ -110,7 +110,7 @@ came from). The MIR is therefore modified in place (which helps to
 keep things efficient).
 
 A good example of a basic MIR pass is [`NoLandingPads`], which walks
-the MIR and removes all edges that are due to unwinding -- this is
+the MIR and removes all edges that are due to unwinding – this is
 used when configured with `panic=abort`, which never unwinds. As you
 can see from its source, a MIR pass is defined by first defining a
 dummy type, a struct with no fields, something like:

src/mir/regionck.md

@@ -12,13 +12,13 @@ The MIR-based region analysis consists of two major functions:
 - `replace_regions_in_mir`, invoked first, has two jobs:
   - First, it finds the set of regions that appear within the
     signature of the function (e.g., `'a` in `fn foo<'a>(&'a u32) {
-    ... }`). These are called the "universal" or "free" regions -- in
+    ... }`). These are called the "universal" or "free" regions – in
     particular, they are the regions that [appear free][fvb] in the
     function body.
   - Second, it replaces all the regions from the function body with
     fresh inference variables. This is because (presently) those
     regions are the results of lexical region inference and hence are
-    not of much interest. The intention is that -- eventually -- they
+    not of much interest. The intention is that – eventually – they
     will be "erased regions" (i.e., no information at all), since we
     won't be doing lexical region inference at all.
 - `compute_regions`, invoked second: this is given as argument the
@@ -40,11 +40,11 @@ The MIR-based region analysis consists of two major functions:
 
 ## Universal regions
 
-*to be written* -- explain the `UniversalRegions` type
+*to be written* – explain the `UniversalRegions` type
 
 ## Region variables and constraints
 
-*to be written* -- describe the `RegionInferenceContext` and
+*to be written* – describe the `RegionInferenceContext` and
 the role of `liveness_constraints` vs other `constraints`, plus
 
 ## Closures
@@ -79,13 +79,13 @@ The kinds of region elements are as follows:
 - Similarly, there is an element denoted `end('static)` corresponding
   to the remainder of program execution after this function returns.
 - There is an element `!1` for each skolemized region `!1`. This
-  corresponds (intuitively) to some unknown set of other elements --
+  corresponds (intuitively) to some unknown set of other elements –
   for details on skolemization, see the section
   [skolemization and universes](#skol).
 
 ## Causal tracking
 
-*to be written* -- describe how we can extend the values of a variable
+*to be written* – describe how we can extend the values of a variable
  with causal tracking etc
 
 <a name="skol"></a>
@@ -133,7 +133,7 @@ bound in the supertype and **skolemizing** them: this means that we
 replace them with
 [universally quantified](appendix/background.html#quantified)
 representatives, written like `!1`. We call these regions "skolemized
-regions" -- they represent, basically, "some unknown region".
+regions" – they represent, basically, "some unknown region".
 
 Once we've done that replacement, we have the following relation:
 
@@ -156,9 +156,9 @@ we swap the left and right here):
 ```
 
 According to the basic subtyping rules for a reference, this will be
-true if `'!1: 'static`. That is -- if "some unknown region `!1`" lives
-outlives `'static`. Now, this *might* be true -- after all, `'!1`
-could be `'static` -- but we don't *know* that it's true. So this
+true if `'!1: 'static`. That is – if "some unknown region `!1`" lives
+outlives `'static`. Now, this *might* be true – after all, `'!1`
+could be `'static` – but we don't *know* that it's true. So this
 should yield up an error (eventually).
 
 ### What is a universe
@@ -238,16 +238,16 @@ not U1.
 **Giving existential variables a universe.** Now that we have this
 notion of universes, we can use it to extend our type-checker and
 things to prevent illegal names from leaking out. The idea is that we
-give each inference (existential) variable -- whether it be a type or
-a lifetime -- a universe. That variable's value can then only
+give each inference (existential) variable – whether it be a type or
+a lifetime – a universe. That variable's value can then only
 reference names visible from that universe. So for example is a
 lifetime variable is created in U0, then it cannot be assigned a value
 of `!1` or `!2`, because those names are not visible from the universe
 U0.
 
 **Representing universes with just a counter.** You might be surprised
 to see that the compiler doesn't keep track of a full tree of
-universes. Instead, it just keeps a counter -- and, to determine if
+universes. Instead, it just keeps a counter – and, to determine if
 one universe can see another one, it just checks if the index is
 greater. For example, U2 can see U0 because 2 >= 0. But U0 cannot see
 U2, because 0 >= 2 is false.
@@ -323,12 +323,12 @@ Now there are two ways that could happen. First, if `U(V1)` can see
 the universe `x` (i.e., `x <= U(V1)`), then we can just add `skol(x)`
 to `value(V1)` and be done. But if not, then we have to approximate:
 we may not know what set of elements `skol(x)` represents, but we
-should be able to compute some sort of **upper bound** B for it --
+should be able to compute some sort of **upper bound** B for it –
 some region B that outlives `skol(x)`. For now, we'll just use
-`'static` for that (since it outlives everything) -- in the future, we
+`'static` for that (since it outlives everything) – in the future, we
 can sometimes be smarter here (and in fact we have code for doing this
 already in other contexts). Moreover, since `'static` is in the root
-universe U0, we know that all variables can see it -- so basically if
+universe U0, we know that all variables can see it – so basically if
 we find that `value(V2)` contains `skol(x)` for some universe `x`
 that `V1` can't see, then we force `V1` to `'static`.
 
@@ -398,8 +398,8 @@ outlives relationships are satisfied. Then we would go to the "check
 universal regions" portion of the code, which would test that no
 universal region grew too large.
 
-In this case, `V1` *did* grow too large -- it is not known to outlive
-`end('static)`, nor any of the CFG -- so we would report an error.
+In this case, `V1` *did* grow too large – it is not known to outlive
+`end('static)`, nor any of the CFG – so we would report an error.
 
 ## Another example
 

src/mir/visitor.md

@@ -2,7 +2,7 @@
 
 The MIR visitor is a convenient tool for traversing the MIR and either
 looking for things or making changes to it. The visitor traits are
-defined in [the `rustc::mir::visit` module][m-v] -- there are two of
+defined in [the `rustc::mir::visit` module][m-v] – there are two of
 them, generated via a single macro: `Visitor` (which operates on a
 `&Mir` and gives back shared references) and `MutVisitor` (which
 operates on a `&mut Mir` and gives back mutable references).

src/query.md

@@ -5,7 +5,7 @@ Rust compiler is current transitioning from a traditional "pass-based"
 setup to a "demand-driven" system. **The Compiler Query System is the
 key to our new demand-driven organization.** The idea is pretty
 simple. You have various queries that compute things about the input
--- for example, there is a query called `type_of(def_id)` that, given
+– for example, there is a query called `type_of(def_id)` that, given
 the def-id of some item, will compute the type of that item and return
 it to you.
 

src/tests/adding.md

@@ -49,8 +49,8 @@ considered an ideal setup.
 
 [`src/test/run-pass`]: https://github.com/rust-lang/rust/tree/master/src/test/run-pass/
 
-For regression tests -- basically, some random snippet of code that
-came in from the internet -- we often just name the test after the
+For regression tests – basically, some random snippet of code that
+came in from the internet – we often just name the test after the
 issue. For example, `src/test/run-pass/issue-12345.rs`. If possible,
 though, it is better if you can put the test into a directory that
 helps identify what piece of code is being tested here (e.g.,
@@ -267,9 +267,9 @@ can also make UI tests where compilation is expected to succeed, and
 you can even run the resulting program. Just add one of the following
 [header commands](#header_commands):
 
-- `// compile-pass` -- compilation should succeed but do
+- `// compile-pass` – compilation should succeed but do
   not run the resulting binary
-- `// run-pass` -- compilation should succeed and we should run the
+- `// run-pass` – compilation should succeed and we should run the
   resulting binary
 
 <a name="bless"></a>