rustc-dev-guide subtree update

src/doc/rustc-dev-guide/ci/sembr/src/main.rs

@@ -27,7 +27,8 @@ static REGEX_IGNORE: LazyLock<Regex> =
 static REGEX_IGNORE_END: LazyLock<Regex> = LazyLock::new(|| Regex::new(r"(\.|\?|;|!)$").unwrap());
 static REGEX_IGNORE_LINK_TARGETS: LazyLock<Regex> =
     LazyLock::new(|| Regex::new(r"^\[.+\]: ").unwrap());
-static REGEX_SPLIT: LazyLock<Regex> = LazyLock::new(|| Regex::new(r"(\.|[^r]\?|;|!)\s+").unwrap());
+static REGEX_SPLIT: LazyLock<Regex> =
+    LazyLock::new(|| Regex::new(r"([^\.]\.|[^r]\?|;|!)\s+").unwrap());
 
 fn main() -> Result<()> {
     let cli = Cli::parse();
@@ -136,6 +137,7 @@ fn lengthen_lines(content: &str, limit: usize) -> String {
     let mut new_content = content.clone();
     let mut new_n = 0;
     let mut in_code_block = false;
+    let mut in_html_div = false;
     let mut skip_next = false;
     for (n, line) in content.iter().enumerate() {
         if skip_next {
@@ -149,6 +151,17 @@ fn lengthen_lines(content: &str, limit: usize) -> String {
             in_code_block = !in_code_block;
             continue;
         }
+        if line.trim_start().starts_with("<div") {
+            in_html_div = true;
+            continue;
+        }
+        if line.trim_start().starts_with("</div") {
+            in_html_div = false;
+            continue;
+        }
+        if in_html_div {
+            continue;
+        }
         if ignore(line, in_code_block) || REGEX_SPLIT.is_match(line) {
             continue;
         }
@@ -183,6 +196,7 @@ ignore E.g. too
 some code. block
 ```
 sentence with *italics* should not be ignored. truly.
+git log main.. compiler
 ";
     let expected = "\
 # some. heading
@@ -203,6 +217,7 @@ some code. block
 ```
 sentence with *italics* should not be ignored.
 truly.
+git log main.. compiler
 ";
     assert_eq!(expected, comply(original));
 }
@@ -212,9 +227,15 @@ fn test_prettify() {
     let original = "\
 do not split
 short sentences
+<div class='warning'>
+a bit of text inside
+</div>
 ";
     let expected = "\
 do not split short sentences
+<div class='warning'>
+a bit of text inside
+</div>
 ";
     assert_eq!(expected, lengthen_lines(original, 50));
 }

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

@@ -1 +1 @@
-c5dabe8cf798123087d094f06417f5a767ca73e8
+8401398e1f14a24670ee1a3203713dc2f0f8b3a8

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

@@ -4,11 +4,11 @@ In the near future, `std::autodiff` should become available in nightly builds fo
 
 ## Build instructions
 
-First you need to clone and configure the Rust repository:
+First you need to clone and configure the Rust repository. Based on your preferences, you might also want to `--enable-clang` or `--enable-lld`.
 ```bash
 git clone git@github.com:rust-lang/rust
 cd rust
-./configure --release-channel=nightly --enable-llvm-enzyme --enable-llvm-assertions --enable-option-checking --disable-docs --set llvm.download-ci-llvm=true
+./configure --release-channel=nightly --enable-llvm-enzyme --enable-llvm-link-shared --enable-llvm-assertions --enable-ninja --enable-option-checking --disable-docs --set llvm.download-ci-llvm=false
 ```
 
 Afterwards you can build rustc using:
@@ -47,7 +47,7 @@ Then build rustc in a slightly altered way:
 ```bash
 git clone https://github.com/rust-lang/rust
 cd rust
-./configure --release-channel=nightly --enable-llvm-enzyme --enable-llvm-assertions --enable-option-checking --disable-docs --set llvm.download-ci-llvm=true
+./configure --release-channel=nightly --enable-llvm-enzyme --enable-llvm-link-shared --enable-llvm-assertions --enable-ninja --enable-option-checking --disable-docs --set llvm.download-ci-llvm=false
 ./x dist
 ```
 We then copy the tarball to our host. The dockerid is the newest entry under `docker ps -a`.

src/doc/rustc-dev-guide/src/borrow_check/two_phase_borrows.md

@@ -15,7 +15,7 @@ two-phase borrow are:
 
 To give some examples:
 
-```rust2018
+```rust,edition2018
 // In the source code
 
 // Case 1:

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

@@ -28,7 +28,7 @@ conditions that trigger the bug, or part of the error message if there is any.
 An example could be: **"impossible case reached" on lifetime inference for impl
 Trait in return position**.
 
-Opening an issue is as easy as following [thi link][create an issue] and filling out the fields
+Opening an issue is as easy as following [this link][create an issue] and filling out the fields
 in the appropriate provided template.
 
 ## Bug fixes or "normal" code changes

src/doc/rustc-dev-guide/src/coroutine-closures.md

@@ -167,7 +167,7 @@ We introduce a `AsyncFnKindHelper` trait which allows us to defer the question o
 
 This seems a bit roundabout and complex, and I admit that it is. But let's think of the "do nothing" alternative -- we could instead mark all `AsyncFn*` goals as ambiguous until upvar analysis, at which point we would know exactly what to put into the upvars of the coroutine we return. However, this is actually *very* detrimental to inference in the program, since it means that programs like this would not be valid:
 
-```rust!
+```rust,ignore
 let c = async || -> String { .. };
 let s = c().await;
 // ^^^ If we can't project `<{c} as AsyncFn>::call()` to a coroutine, then the `IntoFuture::into_future` call inside of the `.await` stalls, and the type of `s` is left unconstrained as an infer var.

src/doc/rustc-dev-guide/src/getting-started.md

@@ -1,14 +1,15 @@
 # Getting Started
 
-Thank you for your interest in contributing to Rust! There are many ways to
-contribute, and we appreciate all of them.
+Thank you for your interest in contributing to Rust!
+There are many ways to contribute, and we appreciate all of them.
 
 If this is your first time contributing, the [walkthrough] chapter can give you a good example of
 how a typical contribution would go.
 
-This documentation is _not_ intended to be comprehensive; it is meant to be a
-quick guide for the most useful things. For more information, [see this
-chapter on how to build and run the compiler](./building/how-to-build-and-run.md).
+This documentation is _not_ intended to be comprehensive;
+it is meant to be a quick guide for the most useful things.
+For more information,
+see [How to build and run the compiler](building/how-to-build-and-run.md).
 
 [internals]: https://internals.rust-lang.org
 [rust-zulip]: https://rust-lang.zulipchat.com
@@ -36,26 +37,30 @@ questions about how the compiler works can go in [#t-compiler/help][z-help].
 [z-help]: https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp
 
 **Please ask questions!** A lot of people report feeling that they are "wasting
-expert's time", but nobody on `t-compiler` feels this way. Contributors are
-important to us.
+expert's time", but nobody on `t-compiler` feels this way.
+Contributors are important to us.
 
 Also, if you feel comfortable, prefer public topics, as this means others can
-see the questions and answers, and perhaps even integrate them back into this
-guide :)
+see the questions and answers, and perhaps even integrate them back into this guide :)
 
-**Tip**: If you're not a native English speaker and feel unsure about writing, try using a translator to help. But avoid using LLM tools that generate long, complex words. In daily teamwork, **simple and clear words** are best for easy understanding. Even small typos or grammar mistakes can make you seem more human, and people connect better with humans.
+**Tip**: If you're not a native English speaker and feel unsure about writing, try using a translator to help.
+But avoid using LLM tools that generate long, complex words.
+In daily teamwork, **simple and clear words** are best for easy understanding.
+Even small typos or grammar mistakes can make you seem more human, and people connect better with humans.
 
 ### Experts
 
-Not all `t-compiler` members are experts on all parts of `rustc`; it's a
-pretty large project. To find out who could have some expertise on
+Not all `t-compiler` members are experts on all parts of `rustc`;
+it's a pretty large project.
+To find out who could have some expertise on
 different parts of the compiler, [consult triagebot assign groups][map].
-The sections that start with `[assign*` in `triagebot.toml` file. 
+The sections that start with `[assign*` in `triagebot.toml` file.
 But also, feel free to ask questions even if you can't figure out who to ping.
 
 Another way to find experts for a given part of the compiler is to see who has made recent commits.
 For example, to find people who have recently worked on name resolution since the 1.68.2 release,
-you could run `git shortlog -n 1.68.2.. compiler/rustc_resolve/`. Ignore any commits starting with
+you could run `git shortlog -n 1.68.2.. compiler/rustc_resolve/`.
+Ignore any commits starting with
 "Rollup merge" or commits by `@bors` (see [CI contribution procedures](./contributing.md#ci) for
 more information about these commits).
 
@@ -64,8 +69,7 @@ more information about these commits).
 ### Etiquette
 
 We do ask that you be mindful to include as much useful information as you can
-in your question, but we recognize this can be hard if you are unfamiliar with
-contributing to Rust.
+in your question, but we recognize this can be hard if you are unfamiliar with contributing to Rust.
 
 Just pinging someone without providing any context can be a bit annoying and
 just create noise, so we ask that you be mindful of the fact that the
@@ -74,13 +78,16 @@ just create noise, so we ask that you be mindful of the fact that the
 ## What should I work on?
 
 The Rust project is quite large and it can be difficult to know which parts of the project need
-help, or are a good starting place for beginners. Here are some suggested starting places.
+help, or are a good starting place for beginners.
+Here are some suggested starting places.
 
 ### Easy or mentored issues
 
 If you're looking for somewhere to start, check out the following [issue
-search][help-wanted-search]. See the [Triage] for an explanation of these labels. You can also try
-filtering the search to areas you're interested in. For example:
+search][help-wanted-search].
+See the [Triage] for an explanation of these labels.
+You can also try filtering the search to areas you're interested in.
+For example:
 
 - `repo:rust-lang/rust-clippy` will only show clippy issues
 - `label:T-compiler` will only show issues related to the compiler
@@ -94,8 +101,9 @@ See below for how to find work that isn't labelled.
 
 ### Recurring work
 
-Some work is too large to be done by a single person. In this case, it's common to have "Tracking
-issues" to co-ordinate the work between contributors. Here are some example tracking issues where
+Some work is too large to be done by a single person.
+In this case, it's common to have "Tracking issues" to co-ordinate the work between contributors.
+Here are some example tracking issues where
 it's easy to pick up work without a large time commitment:
 
 - *Add recurring work items here.*
@@ -105,8 +113,8 @@ If you find more recurring work, please feel free to add it here!
 ### Clippy issues
 
 The [Clippy] project has spent a long time making its contribution process as friendly to newcomers
-as possible. Consider working on it first to get familiar with the process and the compiler
-internals.
+as possible.
+Consider working on it first to get familiar with the process and the compiler internals.
 
 See [the Clippy contribution guide][clippy-contributing] for instructions on getting started.
 
@@ -116,27 +124,33 @@ See [the Clippy contribution guide][clippy-contributing] for instructions on get
 ### Diagnostic issues
 
 Many diagnostic issues are self-contained and don't need detailed background knowledge of the
-compiler. You can see a list of diagnostic issues [here][diagnostic-issues].
+compiler.
+You can see a list of diagnostic issues [here][diagnostic-issues].
 
 [diagnostic-issues]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+label%3AA-diagnostics+no%3Aassignee
 
 ### Picking up abandoned pull requests
 
 Sometimes, contributors send a pull request, but later find out that they don't have enough
-time to work on it, or they simply are not interested in it anymore. Such PRs are often
-eventually closed and they receive the `S-inactive` label. You could try to examine some of
-these PRs and pick up the work. You can find the list of such PRs [here][abandoned-prs].
+time to work on it, or they simply are not interested in it anymore.
+Such PRs are often eventually closed and they receive the `S-inactive` label.
+You could try to examine some of these PRs and pick up the work.
+You can find the list of such PRs [here][abandoned-prs].
 
 If the PR has been implemented in some other way in the meantime, the `S-inactive` label
-should be removed from it. If not, and it seems that there is still interest in the change,
+should be removed from it.
+If not, and it seems that there is still interest in the change,
 you can try to rebase the pull request on top of the latest `master` branch and send a new
 pull request, continuing the work on the feature.
 
 [abandoned-prs]: https://github.com/rust-lang/rust/pulls?q=is%3Apr+label%3AS-inactive+is%3Aclosed
 
 ### Writing tests
 
-Issues that have been resolved but do not have a regression test are marked with the `E-needs-test` label. Writing unit tests is a low-risk, lower-priority task that offers new contributors a great opportunity to familiarize themselves with the testing infrastructure and contribution workflow.
+Issues that have been resolved but do not have a regression test are marked with the `E-needs-test` label.
+Writing unit tests is a low-risk,
+lower-priority task that offers new contributors a great opportunity to familiarize themselves
+with the testing infrastructure and contribution workflow.
 
 ### Contributing to std (standard library)
 
@@ -147,28 +161,28 @@ See [std-dev-guide](https://std-dev-guide.rust-lang.org/).
 There are a bunch of other projects that you can contribute to outside of the
 `rust-lang/rust` repo, including `cargo`, `miri`, `rustup`, and many others.
 
-These repos might have their own contributing guidelines and procedures. Many
-of them are owned by working groups. For more info, see the documentation in those repos' READMEs.
+These repos might have their own contributing guidelines and procedures.
+Many of them are owned by working groups.
+For more info, see the documentation in those repos' READMEs.
 
 ### Other ways to contribute
 
 There are a bunch of other ways you can contribute, especially if you don't
 feel comfortable jumping straight into the large `rust-lang/rust` codebase.
 
-The following tasks are doable without much background knowledge but are
-incredibly helpful:
+The following tasks are doable without much background knowledge but are incredibly helpful:
 
 - [Writing documentation][wd]: if you are feeling a bit more intrepid, you could try
-  to read a part of the code and write doc comments for it. This will help you
-  to learn some part of the compiler while also producing a useful artifact!
+  to read a part of the code and write doc comments for it.
+  This will help you to learn some part of the compiler while also producing a useful artifact!
 - [Triaging issues][triage]: categorizing, replicating, and minimizing issues is very helpful to the Rust maintainers.
 - [Working groups][wg]: there are a bunch of working groups on a wide variety
   of rust-related things.
 - Answer questions on [users.rust-lang.org][users], or on [Stack Overflow][so].
 - Participate in the [RFC process](https://github.com/rust-lang/rfcs).
 - Find a [requested community library][community-library], build it, and publish
-  it to [Crates.io](http://crates.io). Easier said than done, but very, very
-  valuable!
+  it to [Crates.io](http://crates.io).
+  Easier said than done, but very, very valuable!
 
 [users]: https://users.rust-lang.org/
 [so]: http://stackoverflow.com/questions/tagged/rust

src/doc/rustc-dev-guide/src/offload/usage.md

@@ -79,7 +79,7 @@ Now we generate the device code. Replace the target-cpu with the right code for
 RUSTFLAGS="-Ctarget-cpu=gfx90a --emit=llvm-bc,llvm-ir" cargo +offload build -Zunstable-options -r -v --target amdgcn-amd-amdhsa -Zbuild-std=core
 ```
 
-Now find the <libname>.ll under target/amdgcn-amd-amdhsa folder and copy it to a device.ll file (or adjust the file names below).
+Now find the `<libname>.ll` under target/amdgcn-amd-amdhsa folder and copy it to a device.ll file (or adjust the file names below).
 If you work on an NVIDIA or Intel gpu, please adjust the names acordingly and open an issue to share your results (either if you succeed or fail).
 First we compile our .ll files (good for manual inspections) to .bc files and clean up leftover artifacts. The cleanup is important, otherwise caching might interfere on following runs.
 ```