Update some links and docs

src/borrow_check/region_inference.md

@@ -78,13 +78,12 @@ The value of a region can be thought of as a **set**. This set contains all
 points in the MIR where the region is valid along with any regions that are
 outlived by this region (e.g. if `'a: 'b`, then `end('b)` is in the set for
 `'a`); we call the domain of this set a `RegionElement`. In the code, the value
-for all regions is maintained in [the
-`rustc_mir::borrow_check::nll::region_infer` module][ri]. For each region we
-maintain a set storing what elements are present in its value (to make this
+for all regions is maintained in [the `rustc_borrowck::region_infer` module][ri].
+For each region we maintain a set storing what elements are present in its value (to make this
 efficient, we give each kind of element an index, the `RegionElementIndex`, and
 use sparse bitsets).
 
-[ri]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_mir/src/borrow_check/region_infer/
+[ri]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_borrowck/src/region_infer
 
 The kinds of region elements are as follows:
 

src/building/suggested.md

@@ -3,16 +3,16 @@
 The full bootstrapping process takes quite a while. Here are some suggestions
 to make your life easier.
 
-## Installing a pre-commit hook
+## Installing a pre-push hook
 
 CI will automatically fail your build if it doesn't pass `tidy`, our
 internal tool for ensuring code quality. If you'd like, you can install a
 [Git hook](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)
-that will automatically run `./x.py test tidy --bless` on each commit, to ensure
+that will automatically run `./x.py test tidy --bless` on each push, to ensure
 your code is up to par. If you decide later that this behavior is
-undesirable, you can delete the `pre-commit` file in `.git/hooks`.
+undesirable, you can delete the `pre-push` file in `.git/hooks`.
 
-A prebuilt git hook lives at [`src/etc/pre-commit.sh`](https://github.com/rust-lang/rust/blob/master/src/etc/pre-commit.sh) which can be copied into your `.git/hooks` folder as `pre-commit` (without the `.sh` extension!).
+A prebuilt git hook lives at [`src/etc/pre-push.sh`](https://github.com/rust-lang/rust/blob/master/src/etc/pre-push.sh) which can be copied into your `.git/hooks` folder as `pre-push` (without the `.sh` extension!).
 
 You can also install the hook as a step of running `./x.py setup`!
 

src/contributing.md

@@ -67,8 +67,8 @@ where contributors push changes to their personal fork and create pull requests
 bring those changes into the source repository. We have more info about how to use git
 when contributing to Rust under [the git section](./git.md).
 
-[about-pull-requests]: https://help.github.com/articles/about-pull-requests/
-[development-models]: https://help.github.com/articles/about-collaborative-development-models/
+[about-pull-requests]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests
+[development-models]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models#fork-and-pull-model
 
 ### r?
 
@@ -177,7 +177,7 @@ particularly during rebasing, citing the issue number in the commit can "spam"
 the issue in question.
 
 [labeling]: ./rustbot.md#issue-relabeling
-[closing-keywords]: https://help.github.com/en/articles/closing-issues-using-keywords
+[closing-keywords]: https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue
 
 ### External Dependencies (subtree)
 

src/git.md

@@ -18,7 +18,7 @@ more in depth [book from Git].
 
 [book from Git]: https://git-scm.com/book/en/v2/
 [atlassian-git]: https://www.atlassian.com/git/tutorials/what-is-version-control
-[documentation]: https://docs.github.com/en/github/getting-started-with-github/set-up-git
+[documentation]: https://docs.github.com/en/get-started/quickstart/set-up-git
 [guides]: https://guides.github.com/introduction/git-handbook/
 
 ## Prerequisites

src/macro-expansion.md

@@ -227,7 +227,7 @@ only within the macro (i.e. it should not be visible outside the macro).
 [code_dir]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_expand/src/mbe
 [code_mp]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser
 [code_mr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_rules
-[code_parse_int]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser/fn.parse_tt.html
+[code_parse_int]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser/struct.TtParser.html#method.parse_tt
 [parsing]: ./the-parser.html
 
 The context is attached to AST nodes. All AST nodes generated by macros have
@@ -503,9 +503,10 @@ The interface of the macro parser is as follows (this is slightly simplified):
 
 ```rust,ignore
 fn parse_tt(
-    parser: &mut Cow<Parser>,
-    ms: &[TokenTree],
-) -> NamedParseResult
+    &mut self,
+    parser: &mut Cow<'_, Parser<'_>>,
+    matcher: &[MatcherLoc]
+) -> ParseResult
 ```
 
 We use these items in macro parser:
@@ -515,20 +516,20 @@ We use these items in macro parser:
   ask the MBE parser to parse. We will consume the raw stream of tokens and
   output a binding of metavariables to corresponding token trees. The parsing
   session can be used to report parser errors.
-- `ms` a _matcher_. This is a sequence of token trees that we want to match
-  the token stream against.
+- `matcher` is a sequence of `MatcherLoc`s that we want to match
+  the token stream against. They're converted from token trees before matching.
 
 In the analogy of a regex parser, the token stream is the input and we are matching it
-against the pattern `ms`. Using our examples, the token stream could be the stream of
-tokens containing the inside of the example invocation `print foo`, while `ms`
+against the pattern `matcher`. Using our examples, the token stream could be the stream of
+tokens containing the inside of the example invocation `print foo`, while `matcher`
 might be the sequence of token (trees) `print $mvar:ident`.
 
-The output of the parser is a `NamedParseResult`, which indicates which of
+The output of the parser is a [`ParseResult`], which indicates which of
 three cases has occurred:
 
-- Success: the token stream matches the given matcher `ms`, and we have produced a binding
+- Success: the token stream matches the given `matcher`, and we have produced a binding
   from metavariables to the corresponding token trees.
-- Failure: the token stream does not match `ms`. This results in an error message such as
+- Failure: the token stream does not match `matcher`. This results in an error message such as
   "No rule expected token _blah_".
 - Error: some fatal error has occurred _in the parser_. For example, this
   happens if there are more than one pattern match, since that indicates
@@ -607,6 +608,7 @@ Because the Rust ABI is unstable, we use the C ABI for this conversion.
 [stablets]: https://doc.rust-lang.org/proc_macro/struct.TokenStream.html
 [pm]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/proc_macro/index.html
 [pms]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/proc_macro_server/index.html
+[`ParseResult`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser/enum.ParseResult.html
 
 TODO: more here. [#1160](https://github.com/rust-lang/rustc-dev-guide/issues/1160)
 

src/query.md

@@ -37,7 +37,7 @@ will in turn demand information about that crate, starting from the
   actual parsing.
 
 Although this vision is not fully realized, large sections of the
-compiler (for example, generating [MIR](./mir/)) currently work exactly like this.
+compiler (for example, generating [MIR](./mir/index.md)) currently work exactly like this.
 
 [^incr-comp-detail]: The ["Incremental Compilation in Detail](queries/incremental-compilation-in-detail.md) chapter gives a more
 in-depth description of what queries are and how they work.

src/tests/running.md

@@ -211,7 +211,7 @@ See [Compare modes](compiletest.md#compare-modes) for more details.
 
 Sometimes it's easier and faster to just run the test by hand.
 Most tests are just `rs` files, so after
-[creating a rustup toolchain](/building/how-to-build-and-run.html#creating-a-rustup-toolchain),
+[creating a rustup toolchain](../building/how-to-build-and-run.md#creating-a-rustup-toolchain),
 you can do something like:
 
 ```bash