Prepare for renaming of rust-lang/rust default branch

.github/workflows/main.yml

@@ -99,6 +99,6 @@ jobs:
     - name: Check for broken links
       run: |
         curl -sSLo linkcheck.sh \
-          https://raw.githubusercontent.com/rust-lang/rust/master/src/tools/linkchecker/linkcheck.sh
+          https://raw.githubusercontent.com/rust-lang/rust/HEAD/src/tools/linkchecker/linkcheck.sh
         # Cannot use --all here because of the generated redirect pages aren't available.
         sh linkcheck.sh book

README.md

@@ -27,7 +27,7 @@ Building the book requires [mdBook], ideally the same version that
 rust-lang/rust uses in [this file][rust-mdbook]. To get it:
 
 [mdBook]: https://github.com/rust-lang/mdBook
-[rust-mdbook]: https://github.com/rust-lang/rust/blob/master/src/tools/rustbook/Cargo.toml
+[rust-mdbook]: https://github.com/rust-lang/rust/blob/HEAD/src/tools/rustbook/Cargo.toml
 
 ```bash
 $ cargo install mdbook --locked --version <version_num>

nostarch/appendix.md

@@ -777,6 +777,10 @@ the Translations label at *https://github.com/rust-lang/book/issues?q=is%3Aopen+
 * हिंदी at *https://github.com/venkatarun95/rust-book-hindi*
 * ไทย at *https://github.com/rust-lang-th/book-th*
 * Danske at *https://github.com/DanKHansen/book-dk*
+* O’zbek at *https://github.com/rust-lang-uz/book*
+* Tiếng Việt at *https://github.com/tuanemdev/rust-book-vn*
+* Italiano at *https://nixxo.github.io/rust-lang-book-it/*
+* বাংলা at *https://github.com/IsmailHosenIsmailJames/rust-book-bn*
 
 ## Appendix G - How Rust is Made and “Nightly Rust”
 
@@ -799,7 +803,7 @@ bring you new features, fewer bugs, and faster compile times.
 ### Choo, Choo! Release Channels and Riding the Trains
 
 Rust development operates on a *train schedule*. That is, all development is
-done on the `master` branch of the Rust repository. Releases follow a software
+done in the main branch of the Rust repository. Releases follow a software
 release train model, which has been used by Cisco IOS and other software
 projects. There are three *release channels* for Rust:
 
@@ -813,7 +817,7 @@ try out experimental new features may use nightly or beta.
 Here’s an example of how the development and release process works: let’s
 assume that the Rust team is working on the release of Rust 1.5. That release
 happened in December of 2015, but it will provide us with realistic version
-numbers. A new feature is added to Rust: a new commit lands on the `master`
+numbers. A new feature is added to Rust: a new commit lands on the main
 branch. Each night, a new nightly version of Rust is produced. Every day is a
 release day, and these releases are created by our release infrastructure
 automatically. So as time passes, our releases look like this, once a night:
@@ -823,7 +827,7 @@ nightly: * - - * - - *
 ```
 
 Every six weeks, it’s time to prepare a new release! The `beta` branch of the
-Rust repository branches off from the `master` branch used by nightly. Now,
+Rust repository branches off from the main branch used by nightly. Now,
 there are two releases:
 
 ```
@@ -844,8 +848,8 @@ beta:                *
 
 Let’s say a regression is found. Good thing we had some time to test the beta
 release before the regression snuck into a stable release! The fix is applied
-to `master`, so that nightly is fixed, and then the fix is backported to the
-`beta` branch, and a new release of beta is produced:
+to the main branch, so that nightly is fixed, and then the fix is backported to
+the `beta` branch, and a new release of beta is produced:
 
 ```
 nightly: * - - * - - * - - * - - * - - *
@@ -904,9 +908,9 @@ each version is supported for six weeks.
 
 There’s one more catch with this release model: unstable features. Rust uses a
 technique called “feature flags” to determine what features are enabled in a
-given release. If a new feature is under active development, it lands on
-`master`, and therefore, in nightly, but behind a *feature flag*. If you, as a
-user, wish to try out the work-in-progress feature, you can, but you must be
+given release. If a new feature is under active development, it lands on the
+main branch, and therefore, in nightly, but behind a *feature flag*. If you, as
+a user, wish to try out the work-in-progress feature, you can, but you must be
 using a nightly release of Rust and annotate your source code with the
 appropriate flag to opt in.
 
@@ -975,8 +979,8 @@ there’s consensus to accept or reject the feature.
 If the feature is accepted, an issue is opened on the Rust repository, and
 someone can implement it. The person who implements it very well may not be the
 person who proposed the feature in the first place! When the implementation is
-ready, it lands on the `master` branch behind a feature gate, as we discussed
-in the “Unstable Features” section.
+ready, it lands on the main branch behind a feature gate, as we discussed in
+the “Unstable Features” section.
 
 After some time, once Rust developers who use nightly releases have been able
 to try out the new feature, team members will discuss the feature, how it’s

packages/tools/src/bin/link2print.rs

@@ -364,7 +364,7 @@ note: required by `std::fmt::Display::fmt`
 
 [I'm a reference-style link][Arbitrary case-insensitive reference text]
 
-[I'm a relative reference to a repository file](../blob/master/LICENSE)
+[I'm a relative reference to a repository file](../blob/HEAD/LICENSE)
 
 [You can use numbers for reference-style link definitions][1]
 
@@ -387,7 +387,7 @@ I'm an inline-style link with title at *https://www.google.com*
 
 I'm a reference-style link at *https://www.mozilla.org*
 
-I'm a relative reference to a repository file at *../blob/master/LICENSE*
+I'm a relative reference to a repository file at *../blob/HEAD/LICENSE*
 
 You can use numbers for reference-style link definitions at *http://slashdot.org*
 

redirects/release-channels.md

@@ -22,7 +22,7 @@ You can check out other resources that describe release channels.
 
 [1]: https://doc.rust-lang.org/1.30.0/book/first-edition/release-channels.html
 [2]: appendix-07-nightly-rust.html
-[3]: https://github.com/rust-lang/rfcs/blob/master/text/0507-release-channels.md
-[4]: https://github.com/rust-lang-nursery/rustup.rs/blob/master/README.md#keeping-rust-up-to-date
+[3]: https://github.com/rust-lang/rfcs/blob/HEAD/text/0507-release-channels.md
+[4]: https://github.com/rust-lang-nursery/rustup.rs/blob/HEAD/README.md#keeping-rust-up-to-date
 [5]: https://www.rust-lang.org/en-US/tools/install
 

src/appendix-07-nightly-rust.md

@@ -19,7 +19,7 @@ bring you new features, fewer bugs, and faster compile times.
 ### Choo, Choo! Release Channels and Riding the Trains
 
 Rust development operates on a _train schedule_. That is, all development is
-done on the `master` branch of the Rust repository. Releases follow a software
+done in the main branch of the Rust repository. Releases follow a software
 release train model, which has been used by Cisco IOS and other software
 projects. There are three _release channels_ for Rust:
 
@@ -33,7 +33,7 @@ try out experimental new features may use nightly or beta.
 Here’s an example of how the development and release process works: let’s
 assume that the Rust team is working on the release of Rust 1.5. That release
 happened in December of 2015, but it will provide us with realistic version
-numbers. A new feature is added to Rust: a new commit lands on the `master`
+numbers. A new feature is added to Rust: a new commit lands on the main
 branch. Each night, a new nightly version of Rust is produced. Every day is a
 release day, and these releases are created by our release infrastructure
 automatically. So as time passes, our releases look like this, once a night:
@@ -43,7 +43,7 @@ nightly: * - - * - - *
 ```
 
 Every six weeks, it’s time to prepare a new release! The `beta` branch of the
-Rust repository branches off from the `master` branch used by nightly. Now,
+Rust repository branches off from the main branch used by nightly. Now,
 there are two releases:
 
 ```text
@@ -64,8 +64,8 @@ beta:                *
 
 Let’s say a regression is found. Good thing we had some time to test the beta
 release before the regression snuck into a stable release! The fix is applied
-to `master`, so that nightly is fixed, and then the fix is backported to the
-`beta` branch, and a new release of beta is produced:
+to the main branch, so that nightly is fixed, and then the fix is backported to
+the `beta` branch, and a new release of beta is produced:
 
 ```text
 nightly: * - - * - - * - - * - - * - - *
@@ -124,9 +124,9 @@ each version is supported for six weeks.
 
 There’s one more catch with this release model: unstable features. Rust uses a
 technique called “feature flags” to determine what features are enabled in a
-given release. If a new feature is under active development, it lands on
-`master`, and therefore, in nightly, but behind a _feature flag_. If you, as a
-user, wish to try out the work-in-progress feature, you can, but you must be
+given release. If a new feature is under active development, it lands on the
+main branch, and therefore, in nightly, but behind a _feature flag_. If you, as
+a user, wish to try out the work-in-progress feature, you can, but you must be
 using a nightly release of Rust and annotate your source code with the
 appropriate flag to opt in.
 
@@ -195,8 +195,8 @@ there’s consensus to accept or reject the feature.
 If the feature is accepted, an issue is opened on the Rust repository, and
 someone can implement it. The person who implements it very well may not be the
 person who proposed the feature in the first place! When the implementation is
-ready, it lands on the `master` branch behind a feature gate, as we discussed
-in the [“Unstable Features”](#unstable-features)<!-- ignore --> section.
+ready, it lands on the main branch behind a feature gate, as we discussed in
+the [“Unstable Features”](#unstable-features)<!-- ignore --> section.
 
 After some time, once Rust developers who use nightly releases have been able
 to try out the new feature, team members will discuss the feature, how it’s