diff --git a/book.toml b/book.toml index 32e2684..50ebd8d 100644 --- a/book.toml +++ b/book.toml @@ -21,7 +21,7 @@ renderer = ["html"] [output.html] git-repository-icon = "fa-github" git-repository-url = "https://github.com/rust-lang/std-dev-guide" -edit-url-template = "https://github.com/rust-lang/std-dev-guide/edit/master/{path}" +edit-url-template = "https://github.com/rust-lang/std-dev-guide/edit/main/{path}" [output.html.redirect] "/feature-lifecycle/stabilization.html" = "/development/stabilization.html" diff --git a/ci/ghpages-deploy.sh b/ci/ghpages-deploy.sh index c77b08e..c1740db 100644 --- a/ci/ghpages-deploy.sh +++ b/ci/ghpages-deploy.sh @@ -163,7 +163,7 @@ incremental_deploy() { 0) echo No changes to files in $deploy_directory. Skipping commit.;; 1) commit+push;; *) - echo git diff exited with code $diff. Aborting. Staying on branch $deploy_branch so you can debug. To switch back to master, use: git symbolic-ref HEAD refs/heads/master && git reset --mixed >&2 + echo git diff exited with code $diff. Aborting. Staying on branch $deploy_branch so you can debug. To switch back to main, use: git symbolic-ref HEAD refs/heads/main && git reset --mixed >&2 return $diff ;; esac diff --git a/ci/linkcheck.sh b/ci/linkcheck.sh index d329a71..613d610 100755 --- a/ci/linkcheck.sh +++ b/ci/linkcheck.sh @@ -21,7 +21,7 @@ elif [ "$CI" = "true" ] ; then # running in PR CI build echo "Checking files changed in $TRAVIS_COMMIT_RANGE: $CHANGED_FILES" set -x else # running locally - COMMIT_RANGE=master... + COMMIT_RANGE=main... CHANGED_FILES=$(git diff --name-only $COMMIT_RANGE | tr '\n' ' ') FLAGS="-f $CHANGED_FILES" diff --git a/src/breaking-changes/new-trait-impls.md b/src/breaking-changes/new-trait-impls.md index 33d4cf8..e5c199c 100644 --- a/src/breaking-changes/new-trait-impls.md +++ b/src/breaking-changes/new-trait-impls.md @@ -36,7 +36,7 @@ let b = Arc::from("a"); will no longer compile, because we've previously been relying on inference to figure out the `T` in `Box`. -This kind of breakage can be ok, but a [crater](https://github.com/rust-lang/crater/blob/master/docs/bot-usage.md) run should estimate the scope. +This kind of breakage can be ok, but a [crater](https://github.com/rust-lang/crater/blob/main/docs/bot-usage.md) run should estimate the scope. ## Deref coercion breaks when a new impl is introduced diff --git a/src/development/perf-benchmarking.md b/src/development/perf-benchmarking.md index dcbb611..69fa236 100644 --- a/src/development/perf-benchmarking.md +++ b/src/development/perf-benchmarking.md @@ -22,7 +22,7 @@ when they instantiate generic library functions, e.g. iterators. ## rustc-perf For parts of the standard library that are heavily used by rustc itself it can be convenient to use -[the benchmark server](https://github.com/rust-lang/rustc-perf/tree/master/collector#benchmarking). +[the benchmark server](https://github.com/rust-lang/rustc-perf/tree/main/collector#benchmarking). Since it only measures compile-time but not runtime performance of crates it can't be used to benchmark for features that aren't used by the compiler, e.g. floating point code, linked lists, mpsc channels, etc. diff --git a/src/development/stabilization.md b/src/development/stabilization.md index d6652b7..7ef8760 100644 --- a/src/development/stabilization.md +++ b/src/development/stabilization.md @@ -11,7 +11,7 @@ Stabilization goes through the Libs FCP (Final Comment Period) process, which ty Once an unstable feature's API design space (e.g. alternative APIs) has been fully explored with no outstanding concerns, anyone may push for its stabilization. -If you're unsure if a feature is ready for stabilization the first step should be to ask in the relevant tracking issue and get assistance from other participants in that discussion. In some cases the tracking issue may not have many other active participants, so if you're ever having trouble getting any feedback please ping one of the [libs team reviewers](https://github.com/rust-lang/rust/blob/master/triagebot.toml) directly to request assistance. +If you're unsure if a feature is ready for stabilization the first step should be to ask in the relevant tracking issue and get assistance from other participants in that discussion. In some cases the tracking issue may not have many other active participants, so if you're ever having trouble getting any feedback please ping one of the [libs team reviewers](https://github.com/rust-lang/rust/blob/main/triagebot.toml) directly to request assistance. ## Stabilization Report @@ -38,7 +38,7 @@ This will save you from opening a stabilization PR and having it need regular re When you only wish to stabilize a subset of an existing feature you should skip creating a new tracking issue and instead create a partial stabilization PR for the subset of the feature being stabilized. -If you're unsure if a feature is ready for partial stabilization the first step should be to ask in the relevant tracking issue and get assistance from other participants in that discussion. In some cases the tracking issue may not have many other active participants, so if you're ever having trouble getting any feedback please ping one of the [libs team reviewers](https://github.com/rust-lang/rust/blob/master/triagebot.toml) directly to request assistance. +If you're unsure if a feature is ready for partial stabilization the first step should be to ask in the relevant tracking issue and get assistance from other participants in that discussion. In some cases the tracking issue may not have many other active participants, so if you're ever having trouble getting any feedback please ping one of the [libs team reviewers](https://github.com/rust-lang/rust/blob/main/triagebot.toml) directly to request assistance. You can see an example of partially stabilizing a feature with tracking issue [#71146](https://github.com/rust-lang/rust/issues/71146) and partial stabilization PR [#94640](https://github.com/rust-lang/rust/pull/94640).