Merge pull request #2748 from rust-lang/tshepang/sembr

sembr

Author: tshepang

ci/sembr/src/main.rs

@@ -24,7 +24,7 @@ static REGEX_IGNORE_END: LazyLock<Regex> =
 static REGEX_IGNORE_LINK_TARGETS: LazyLock<Regex> =
     LazyLock::new(|| Regex::new(r"^\[.+\]: ").unwrap());
 static REGEX_SPLIT: LazyLock<Regex> =
-    LazyLock::new(|| Regex::new(r"([^\.\d\-\*]\.|[^r]\?|!)\s").unwrap());
+    LazyLock::new(|| Regex::new(r"([^\.\d\-\*]\.|[^r\~]\?|!)\s").unwrap());
 // list elements, numbered (1.) or not  (- and *)
 static REGEX_LIST_ENTRY: LazyLock<Regex> =
     LazyLock::new(|| Regex::new(r"^\s*(\d\.|\-|\*|\d\))\s+").unwrap());
@@ -83,6 +83,8 @@ fn ignore(line: &str, in_code_block: bool) -> bool {
         || line.contains(" etc.")
         || line.contains("i.e.")
         || line.contains("et. al")
+        || line.contains("<!--")
+        || line.contains("-->")
         || line.contains('|')
         || line.trim_start().starts_with('>')
         || line.starts_with('#')
@@ -204,6 +206,7 @@ git log main.. compiler
 o? whatever
 r? @reviewer
  r? @reviewer
+~? diagnostic
 ";
     let expected = "
 # some. heading
@@ -236,6 +239,7 @@ o?
 whatever
 r? @reviewer
  r? @reviewer
+~? diagnostic
 ";
     assert_eq!(expected, comply(original));
 }
@@ -263,6 +267,11 @@ leave the
 text alone
 ```
 
+<!-- ignore
+html comment opening
+--> ignore
+html comment closing
+
  handle the
  indented well
 
@@ -289,6 +298,11 @@ leave the
 text alone
 ```
 
+<!-- ignore
+html comment opening
+--> ignore
+html comment closing
+
  handle the indented well
 
 [a target]: https://example.com

src/building/suggested.md

@@ -3,7 +3,8 @@
 > NOTE:
 > There exists much detail about the team [on Forge], making most of the following obsolete.
 
-rustc is maintained by the [Rust compiler team][team]. The people who belong to
+rustc is maintained by the [Rust compiler team][team].
+The people who belong to
 this team collectively work to track regressions and implement new features.
 Members of the Rust compiler team are people who have made significant
 contributions to rustc and its design.
@@ -34,35 +35,32 @@ who are reviewers of each part.
 ## Rust compiler meeting
 
 The compiler team has a weekly meeting where we do triage and try to
-generally stay on top of new bugs, regressions, and discuss important
-things in general.
-They are held on [Zulip][zulip-meetings]. It works roughly as follows:
+generally stay on top of new bugs, regressions, and discuss important things in general.
+They are held on [Zulip][zulip-meetings].
+It works roughly as follows:
 
 - **Announcements, MCPs/FCPs, and WG-check-ins:** We share some
-  announcements with the rest of the team about important things we want
-  everyone to be aware of. We also share the status of MCPs and FCPs and we
-  use the opportunity to have a couple of WGs giving us an update about
-  their work.
+  announcements with the rest of the team about important things we want everyone to be aware of.
+  We also share the status of MCPs and FCPs and we
+  use the opportunity to have a couple of WGs giving us an update about their work.
 - **Check for beta and stable nominations:** These are nominations of things to
   backport to beta and stable respectively.
-  We then look for new cases where the compiler broke previously working
-  code in the wild. Regressions are important issues to fix, so it's
+  We then look for new cases where the compiler broke previously working code in the wild.
+  Regressions are important issues to fix, so it's
   likely that they are tagged as P-critical or P-high; the major
   exception would be bug fixes (though even there we often [aim to give
   warnings first][procedure]).
 - **Review P-critical and P-high bugs:** P-critical and P-high bugs are
-  those that are sufficiently important for us to actively track
-  progress. P-critical and P-high bugs should ideally always have an
-  assignee.
+  those that are sufficiently important for us to actively track progress.
+  P-critical and P-high bugs should ideally always have an assignee.
 - **Check `S-waiting-on-t-compiler` and `I-compiler-nominated` issues:** These are issues where
   feedback from the team is desired.
 - **Look over the performance triage report:** We check for PRs that made the
     performance worse and try to decide if it's worth reverting the performance regression or if
     the regression can be addressed in a future PR.
 
 The meeting currently takes place on Thursdays at 10am Boston time
-(UTC-4 typically, but daylight savings time sometimes makes things
-complicated).
+(UTC-4 typically, but daylight savings time sometimes makes things complicated).
 
 [procedure]: ./bug-fix-procedure.md
 [zulip-t-compiler]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler
@@ -72,17 +70,16 @@ complicated).
 ## Team membership
 
 Membership in the Rust team is typically offered when someone has been
-making significant contributions to the compiler for some
-time. Membership is both a recognition but also an obligation:
+making significant contributions to the compiler for some time.
+Membership is both a recognition but also an obligation:
 compiler team members are generally expected to help with upkeep as
 well as doing reviews and other work.
 
 If you are interested in becoming a compiler team member, the first
-thing to do is to start fixing some bugs, or get involved in a working
-group. One good way to find bugs is to look for
+thing to do is to start fixing some bugs, or get involved in a working group.
+One good way to find bugs is to look for
 [open issues tagged with E-easy](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AE-easy)
-or
-[E-mentor](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AE-mentor).
+or [E-mentor](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AE-mentor).
 
 You can also dig through the graveyard of PRs that were
 [closed due to inactivity](https://github.com/rust-lang/rust/pulls?q=is%3Apr+label%3AS-inactive),
@@ -92,18 +89,17 @@ for which the original author didn't have time.
 
 ### r+ rights
 
-Once you have made a number of individual PRs to rustc, we will often
-offer r+ privileges. This means that you have the right to instruct
-"bors" (the robot that manages which PRs get landed into rustc) to
-merge a PR
+Once you have made a number of individual PRs to rustc, we will often offer r+ privileges.
+This means that you have the right to instruct
+"bors" (the robot that manages which PRs get landed into rustc) to merge a PR
 ([here are some instructions for how to talk to bors][bors-guide]).
 
 [bors-guide]: https://bors.rust-lang.org/
 
 The guidelines for reviewers are as follows:
 
-- You are always welcome to review any PR, regardless of who it is
-  assigned to.  However, do not r+ PRs unless:
+- You are always welcome to review any PR, regardless of who it is assigned to.
+  However, do not r+ PRs unless:
   - You are confident in that part of the code.
   - You are confident that nobody else wants to review it first.
     - For example, sometimes people will express a desire to review a
@@ -119,18 +115,16 @@ The guidelines for reviewers are as follows:
 
 Once you have r+ rights, you can also be added to the [reviewer rotation].
 [triagebot] is the bot that [automatically assigns] incoming PRs to reviewers.
-If you are added, you will be randomly selected to review
-PRs. If you find you are assigned a PR that you don't feel comfortable
+If you are added, you will be randomly selected to review PRs.
+If you find you are assigned a PR that you don't feel comfortable
 reviewing, you can also leave a comment like `r? @so-and-so` to assign
 to someone else — if you don't know who to request, just write `r?
-@nikomatsakis for reassignment` and @nikomatsakis will pick someone
-for you.
+@nikomatsakis for reassignment` and @nikomatsakis will pick someone for you.
 
 [reviewer rotation]: https://github.com/rust-lang/rust/blob/36285c5de8915ecc00d91ae0baa79a87ed5858d5/triagebot.toml#L528-L577
 [triagebot]: https://github.com/rust-lang/triagebot/
 [automatically assigns]: https://forge.rust-lang.org/triagebot/pr-assignment.html
 
-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.
+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.