Use id attribute for <a> tags instead of deprecated name attribute (#2184)

Author: max-heller

src/appendix/background.md

@@ -4,7 +4,7 @@ This section covers a numbers of common compiler terms that arise in
 this guide. We try to give the general definition while providing some
 Rust-specific context.
 
-<a name="cfg"></a>
+<a id="cfg"></a>
 
 ## What is a control-flow graph?
 
@@ -100,7 +100,7 @@ When using a control-flow graph, a loop simply appears as a cycle in
 the graph, and the `break` keyword translates into a path out of that
 cycle.
 
-<a name="dataflow"></a>
+<a id="dataflow"></a>
 
 ## What is a dataflow analysis?
 
@@ -186,7 +186,7 @@ useful. For example, rather than starting from block (A) and moving forwards,
 we might have started with the usage of `x` and moved backwards to try to find
 its initialization.
 
-<a name="quantified"></a>
+<a id="quantified"></a>
 
 ## What is "universally quantified"? What about "existentially quantified"?
 
@@ -233,7 +233,7 @@ fn foo(_: dyn Debug)
 This function claims that there exists some type `T` that implements `Debug`
 such that the function is well-typed: `∃ T:  (T: Debug) and well_typed(foo)`.
 
-<a name="variance"></a>
+<a id="variance"></a>
 
 ## What is a de Bruijn Index?
 
@@ -268,7 +268,7 @@ Check out the subtyping chapter from the
 See the [variance](../variance.html) chapter of this guide for more info on how
 the type checker handles variance.
 
-<a name="free-vs-bound"></a>
+<a id="free-vs-bound"></a>
 
 ## What is a "free region" or a "free variable"? What about "bound region"?
 

src/borrow_check/region_inference.md

@@ -70,7 +70,7 @@ TODO: write about _how_ these regions are computed.
 
 [`UniversalRegions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/universal_regions/struct.UniversalRegions.html
 
-<a name="region-variables"></a>
+<a id="region-variables"></a>
 
 ## Region variables
 

src/borrow_check/region_inference/member_constraints.md

@@ -171,7 +171,7 @@ This choice is consistent with the general 'flow' of region
 propagation, which always aims to compute a minimal value for the
 region being inferred. However, it is somewhat arbitrary.
 
-<a name="collecting"></a>
+<a id="collecting"></a>
 
 ### Collecting upper bounds in the implementation
 

src/bug-fix-procedure.md

@@ -227,7 +227,7 @@ that we use for unstable features:
 Ideally, breaking changes should have landed on the **stable branch** of the
 compiler before they are finalized.
 
-<a name="guide">
+<a id="guide">
 
 ### Removing a lint
 

src/conventions.md

@@ -3,7 +3,7 @@ chapter covers [formatting](#formatting), [coding for correctness](#cc),
 [using crates from crates.io](#cio), and some tips on
 [structuring your PR for easy review](#er).
 
-<a name="formatting"></a>
+<a id="formatting"></a>
 
 # Formatting and the tidy script
 
@@ -40,7 +40,7 @@ When modifying that code, use this command to format it:
 This uses a pinned version of `clang-format`, to avoid relying on the local
 environment.
 
-<a name="copyright"></a>
+<a id="copyright"></a>
 
 <!-- REUSE-IgnoreStart -->
 <!-- Prevent REUSE from interpreting the heading as a copyright notice -->
@@ -71,7 +71,7 @@ that case, you can add a comment towards the top of the file like so:
 
 Prefer 4-space indent.
 
-<a name="cc"></a>
+<a id="cc"></a>
 
 # Coding for correctness
 
@@ -113,13 +113,13 @@ if foo {
 }
 ```
 
-<a name="cio"></a>
+<a id="cio"></a>
 
 # Using crates from crates.io
 
 See the [crates.io dependencies][crates] section.
 
-<a name="er"></a>
+<a id="er"></a>
 
 # How to structure your PR
 

src/hir.md

@@ -74,7 +74,7 @@ the compiler a chance to observe that you accessed the data for
 
 [`&rustc_hir::Item`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/struct.Item.html
 
-<a name="hir-id"></a>
+<a id="hir-id"></a>
 
 ## Identifiers in the HIR
 

src/mir/index.md

@@ -325,7 +325,7 @@ As a consequence, all decoding of `ValTree` must happen by matching on the type
 decisions depending on that. The value itself gives no useful information without the type that
 belongs to it.
 
-<a name="promoted"></a>
+<a id="promoted"></a>
 
 ### Promoted constants
 

src/notification-groups/about.md

@@ -43,7 +43,7 @@ particularly those of **middle priority**:
   can accumulate over time, and the role of the notification group is
   to try and stop that from happening!
 
-<a name="join"></a>
+<a id="join"></a>
 
 ## Joining a notification group
 

src/queries/incremental-compilation.md

@@ -92,7 +92,7 @@ Try-mark-green works as follows:
     - Otherwise, **all** of the nodes in `reads(Q)` must be **green**. In that
       case, we can color Q as **green** and return.
 
-<a name="dag"></a>
+<a id="dag"></a>
 
 ### The query DAG
 

src/stabilization_guide.md

@@ -13,7 +13,7 @@ following steps:
 
 ## Documentation PRs
 
-<a name="updating-documentation"></a>
+<a id="updating-documentation"></a>
 
 If any documentation for this feature exists, it should be
 in the [`Unstable Book`], located at [`src/doc/unstable-book`].

src/tests/adding.md

@@ -180,7 +180,7 @@ if the new output makes sense.
 
 You may also need to re-bless the output with the `--bless` flag.
 
-<a name="explanatory_comment"></a>
+<a id="explanatory_comment"></a>
 
 ## Comment explaining what the test is about
 

src/traits/canonical-queries.md

@@ -95,7 +95,7 @@ Rc<?T>: Clone
 
 After all, `Rc<?T>` is true **no matter what type `?T` is**.
 
-<a name="query-response"></a>
+<a id="query-response"></a>
 
 ## A trait query in rustc
 

src/traits/goals-and-clauses.md

@@ -47,7 +47,7 @@ In terms of code, these types are defined in
 [traits_mod]: https://github.com/rust-lang/rust/blob/master/compiler/rustc_middle/src/traits/mod.rs
 [chalk_ir]: https://github.com/rust-lang/chalk/blob/master/chalk-ir/src/lib.rs
 
-<a name="domain-goals"></a>
+<a id="domain-goals"></a>
 
 ## Domain goals
 
@@ -63,7 +63,7 @@ forall<K1, ..., Kn> { DomainGoal :- Goal }
 hence domain goals are in fact clauses' LHS. That is, at the most granular level,
 domain goals are what the trait solver will end up trying to prove.
 
-<a name="trait-ref"></a>
+<a id="trait-ref"></a>
 
 To define the set of domain goals in our system, we need to first
 introduce a few simple formulations. A **trait reference** consists of
@@ -78,7 +78,7 @@ IntoIterator`. Note that Rust surface syntax also permits some extra
 things, like associated type bindings (`Vec<T>: IntoIterator<Item =
 T>`), that are not part of a trait reference.
 
-<a name="projection"></a>
+<a id="projection"></a>
 
 A **projection** consists of an associated item reference along with
 its inputs P0..Pm:
@@ -205,7 +205,7 @@ e.g. `Outlives(&'a str: 'b)`, `Outlives('a: 'static)`
 
 True if the given type or region on the left outlives the right-hand region.
 
-<a name="coinductive"></a>
+<a id="coinductive"></a>
 
 ## Coinductive goals
 

src/type-inference.md

@@ -51,7 +51,7 @@ The `tcx.infer_ctxt` method actually returns a builder, which means
 there are some kinds of configuration you can do before the `infcx` is
 created. See `InferCtxtBuilder` for more information.
 
-<a name="vars"></a>
+<a id="vars"></a>
 
 ## Inference variables
 

src/variance.md

@@ -143,7 +143,7 @@ will wind up being considered green after it is re-evaluated.
 
 [rga]: ./queries/incremental-compilation.html
 
-<a name="addendum"></a>
+<a id="addendum"></a>
 
 ## Addendum: Variance on traits
 

src/walkthrough.md

@@ -151,7 +151,7 @@ Here is the tracking issue on for our [`?` macro feature][tracking].
 
 [tracking]: https://github.com/rust-lang/rust/issues/48075
 
-<a name="impl"></a>
+<a id="impl"></a>
 
 ## Implementation