Auto merge of #147392 - tshepang:rdg-sync, r=tshepang

rustc-dev-guide subtree update

Subtree update of `rustc-dev-guide` to https://github.com/rust-lang/rustc-dev-guide/commit/5270b840dd7055e5e2717586527ffabc95ecd44e.

Created using https://github.com/rust-lang/josh-sync.

r? `@ghost`

src/doc/rustc-dev-guide/.github/workflows/ci.yml

@@ -3,7 +3,7 @@ name: CI
 on:
   push:
     branches:
-      - master
+      - main
   pull_request:
   schedule:
     # Run multiple times a day as the successfull cached links are not checked every time.

src/doc/rustc-dev-guide/.github/workflows/rustc-pull.yml

@@ -14,7 +14,7 @@ jobs:
       github-app-id: ${{ vars.APP_CLIENT_ID }}
       zulip-stream-id: 196385
       zulip-bot-email:  "rustc-dev-guide-gha-notif-bot@rust-lang.zulipchat.com"
-      pr-base-branch: master
+      pr-base-branch: main
       branch-name: rustc-pull
     secrets:
       zulip-api-token: ${{ secrets.ZULIP_API_TOKEN }}

src/doc/rustc-dev-guide/book.toml

@@ -11,7 +11,7 @@ command = "mdbook-mermaid"
 
 [output.html]
 git-repository-url = "https://github.com/rust-lang/rustc-dev-guide"
-edit-url-template = "https://github.com/rust-lang/rustc-dev-guide/edit/master/{path}"
+edit-url-template = "https://github.com/rust-lang/rustc-dev-guide/edit/main/{path}"
 additional-js = [
   "mermaid.min.js",
   "mermaid-init.js",

src/doc/rustc-dev-guide/ci/linkcheck.sh

@@ -32,7 +32,7 @@ elif [ "$GITHUB_EVENT_NAME" = "pull_request" ] ; then # running in PR CI build
 
   echo "Checking files changed since $BASE_SHA: $CHANGED_FILES"
 else # running locally
-  COMMIT_RANGE=master...
+  COMMIT_RANGE=main...
   CHANGED_FILES=$(git diff --name-only $COMMIT_RANGE | sed 's#^src/##' | tr '\n' ' ')
   FLAGS="-f $CHANGED_FILES"
 

src/doc/rustc-dev-guide/rust-version

@@ -1 +1 @@
-9f32ccf35fb877270bc44a86a126440f04d676d0
+4fa824bb78318a3cba8c7339d5754b4909922547

src/doc/rustc-dev-guide/src/autodiff/debugging.md

@@ -16,7 +16,7 @@ Before generating the llvm-ir, keep in mind two techniques that can help ensure
 ## 1) Generate an llvm-ir reproducer
 
 ```sh
-rustflags="-z autodiff=enable,printmodbefore" cargo +enzyme build --release &> out.ll 
+RUSTFLAGS="-Z autodiff=Enable,PrintModbefore" cargo +enzyme build --release &> out.ll 
 ```
 
 This also captures a few warnings and info messages above and below your module. open out.ll and remove every line above `; moduleid = <somehash>`. Now look at the end of the file and remove everything that's not part of llvm-ir, i.e. remove errors and warnings. The last line of your llvm-ir should now start with `!<somenumber> = `, i.e. `!40831 = !{i32 0, i32 1037508, i32 1037538, i32 1037559}` or `!43760 = !dilocation(line: 297, column: 5, scope: !43746)`.
@@ -25,11 +25,12 @@ The actual numbers will depend on your code.
 
 ## 2) Check your llvm-ir reproducer
 
-To confirm that your previous step worked, we will use llvm's `opt` tool. find your path to the opt binary, with a path similar to `<some_dir>/rust/build/<x86/arm/...-target-tripple>/build/bin/opt`. also find `llvmenzyme-19.<so/dll/dylib>` path, similar to `/rust/build/target-tripple/enzyme/build/enzyme/llvmenzyme-19`. Please keep in mind that llvm frequently updates it's llvm backend, so the version number might be higher (20, 21, ...). Once you have both, run the following command:
+To confirm that your previous step worked, we will use llvm's `opt` tool. find your path to the opt binary, with a path similar to `<some_dir>/rust/build/<x86/arm/...-target-triple>/build/bin/opt`. also find `llvmenzyme-19.<so/dll/dylib>` path, similar to `/rust/build/target-triple/enzyme/build/enzyme/llvmenzyme-19`. Please keep in mind that llvm frequently updates it's llvm backend, so the version number might be higher (20, 21, ...). Once you have both, run the following command:
 
 ```sh
-<path/to/opt> out.ll -load-pass-plugin=/path/to/llvmenzyme-19.so -passes="enzyme" -s
+<path/to/opt> out.ll -load-pass-plugin=/path/to/build/<target-triple>/stage1/lib/libEnzyme-21.so -passes="enzyme" -enzyme-strict-aliasing=0  -s
 ```
+This command might fail for future versions or on your system, in which case you should replace libEnzyme-21.so with LLVMEnzyme-21.so. Look at the Enzyme docs for instructions on how to build it. You might need to also adjust how to build your LLVM version.
 
 If the previous step succeeded, you are going to see the same error that you saw when compiling your rust code with cargo. 
 

src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md

@@ -187,7 +187,7 @@ Alternatively, you can write `bootstrap.toml` by hand. See `bootstrap.example.to
 settings and explanations of them. See `src/bootstrap/defaults` for common settings to change.
 
 If you have already built `rustc` and you change settings related to LLVM, then you may have to
-execute `rm -rf build` for subsequent configuration changes to take effect. Note that `./x
+execute `./x clean --all` for subsequent configuration changes to take effect. Note that `./x
 clean` will not cause a rebuild of LLVM.
 
 ## Common `x` commands
@@ -226,16 +226,17 @@ Once you've created a `bootstrap.toml`, you are now ready to run
 `x`. There are a lot of options here, but let's start with what is
 probably the best "go to" command for building a local compiler:
 
-```bash
-./x build library
+```console
+./x build rustc
 ```
 
-This may *look* like it only builds the standard library, but that is not the case.
-What this command does is the following:
+What this command does is build `rustc` using the stage0 compiler and stage0 `std`.
 
-- Build `rustc` using the stage0 compiler
-  - This produces the stage1 compiler
-- Build `std` using the stage1 compiler
+To build `rustc` with the in-tree `std`, use this command instead:
+
+```console
+./x build rustc --stage 2
+```
 
 This final product (stage1 compiler + libs built using that compiler)
 is what you need to build other Rust programs (unless you use `#![no_std]` or
@@ -253,7 +254,7 @@ signature of some function, you can use `./x check` instead for a much faster bu
 
 Note that this whole command just gives you a subset of the full `rustc`
 build. The **full** `rustc` build (what you get with `./x build
---stage 2 compiler/rustc`) has quite a few more steps:
+--stage 2 rustc`) has quite a few more steps:
 
 - Build `rustc` with the stage1 compiler.
   - The resulting compiler here is called the "stage2" compiler, which uses stage1 std from the previous command.

src/doc/rustc-dev-guide/src/compiler-team.md

@@ -134,12 +134,3 @@ Getting on the reviewer rotation is much appreciated as it lowers the
 review burden for all of us! However, if you don't have time to give
 people timely feedback on their PRs, it may be better that you don't
 get on the list.
-
-### Full team membership
-
-Full team membership is typically extended once someone made many
-contributions to the Rust compiler over time, ideally (but not
-necessarily) to multiple areas. Sometimes this might be implementing a
-new feature, but it is also important — perhaps more important! — to
-have time and willingness to help out with general upkeep such as
-bugfixes, tracking regressions, and other less glamorous work.

src/doc/rustc-dev-guide/src/rustc-driver/intro.md

@@ -34,7 +34,7 @@ specifically [`rustc_driver_impl::run_compiler`][rdi_rc]
 [`rustc_driver`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/
 [`rustc_interface`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/index.html
 [`Callbacks`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/trait.Callbacks.html
-[example]: https://github.com/rust-lang/rustc-dev-guide/blob/master/examples/rustc-interface-example.rs
+[example]: https://github.com/rust-lang/rustc-dev-guide/blob/main/examples/rustc-interface-example.rs
 [i_rc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/fn.run_compiler.html
 [rd_rc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/fn.run_compiler.html
 [rdi_rc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver_impl/fn.run_compiler.html

src/doc/rustc-dev-guide/src/rustdoc.md

@@ -60,6 +60,18 @@ does is call the `main()` that's in this crate's `lib.rs`, though.)
 * Use `./x test tests/rustdoc*` to run the tests using a stage1
   rustdoc.
   * See [Rustdoc internals] for more information about tests.
+* Use `./x.py test tidy --extra-checks=js` to run rustdoc’s JavaScript checks (`eslint`, `es-check`, and `tsc`).
+> **Note:** `./x.py test tidy` already runs these checks automatically when JS/TS sources changed; `--extra-checks=js` forces them explicitly.
+
+### JavaScript CI checks
+
+Rustdoc’s JavaScript and TypeScript are checked during CI by `eslint`, `es-check`, and `tsc` (not by compiletest). These run as part of the `tidy` job.
+
+```bash
+./x.py test tidy --extra-checks=js
+```
+
+The `--extra-checks=js` flag enables the frontend linting that runs in CI.
 
 [`bootstrap.toml`]: ./building/how-to-build-and-run.md
 

src/doc/rustc-dev-guide/src/tests/codegen-backend-tests/cg_gcc.md

@@ -20,7 +20,7 @@ rust.codegen-backends = ["llvm", "gcc"]
 ```
 
 If you don't want to change your `bootstrap.toml` file, you can alternatively run your `x`
-commands with `--set rust.codegen-backends=["llvm", "gcc"]'`. For example:
+commands with `--set 'rust.codegen-backends=["llvm", "gcc"]'`. For example:
 
 ```bash
 ./x build --set 'rust.codegen-backends=["llvm", "gcc"]'

src/doc/rustc-dev-guide/src/tests/directives.md

@@ -264,13 +264,21 @@ Consider writing the test as a proper incremental test instead.
 
 #### The edition directive
 
-The `//@ edition` directive can take an exact edition, a bounded half-open range of editions or a left-bounded half-open range of editions, this affects which edition is used by `./x test` to run the test. For example:
+The `//@ edition` directive can take an exact edition, a bounded range of editions,
+or a left-bounded half-open range of editions.
+This affects which edition is used by `./x test` to run the test.
+
+For example:
 
 - A test with the `//@ edition: 2018` directive will only run under the 2018 edition.
-- A test with the `//@ edition: 2015..2021` directive can be run under both the 2015 and 2018 editions. However, CI will only run the test with the lowest edition possible (2015 in this case).
-- A test with the `//@ edition: 2018..` directive will run under any edition greater or equal than 2018. However, CI will only run the test with the lowest edition possible (2018 in this case).
+- A test with the `//@ edition: 2015..2021` directive can be run under the 2015, 2018, and 2021 editions.
+  However, CI will only run the test with the lowest edition in the range (which is 2015 in this example).
+- A test with the `//@ edition: 2018..` directive will run under 2018 edition or greater.
+  However, CI will only run the test with the lowest edition in the range (which is 2018 in this example).
 
-You can also force `./x test` to use a specific edition by passing the `-- --edition=` argument. However, tests with the `//@ edition` directive will clamp the value passed to the argument. For example, if we run `./x test -- --edition=2015`:
+You can also force `./x test` to use a specific edition by passing the `-- --edition=` argument.
+However, tests with the `//@ edition` directive will clamp the value passed to the argument.
+For example, if we run `./x test -- --edition=2015`:
 
 - A test with the `//@ edition: 2018` will run with the 2018 edition. 
 - A test with the `//@ edition: 2015..2021` will be run with the 2015 edition.