From 9542d616f468e49cd7c1d6b196e7499d569c3115 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Sat, 29 Nov 2025 19:41:44 +0200 Subject: [PATCH 1/3] do not mess with a &[u8; 2] --- ci/sembr/src/main.rs | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ci/sembr/src/main.rs b/ci/sembr/src/main.rs index b74dbbe56..7ace34aed 100644 --- a/ci/sembr/src/main.rs +++ b/ci/sembr/src/main.rs @@ -27,7 +27,7 @@ static REGEX_IGNORE_END: LazyLock = static REGEX_IGNORE_LINK_TARGETS: LazyLock = LazyLock::new(|| Regex::new(r"^\[.+\]: ").unwrap()); static REGEX_SPLIT: LazyLock = - 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 = LazyLock::new(|| Regex::new(r"^\s*(\d\.|\-|\*)\s+").unwrap()); @@ -196,7 +196,7 @@ fn lengthen_lines(content: &str, limit: usize) -> String { fn test_sembr() { let original = " # some. heading -must! be; split? +must! be. split? 1. ignore a dot after number. but no further ignore | tables ignore e.g. and @@ -214,7 +214,7 @@ git log main.. compiler let expected = " # some. heading must! -be; +be. split? 1. ignore a dot after number. but no further From 2bb8a0defaef0cb656aafb4fe0509e49ce4d156d Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Sat, 29 Nov 2025 19:42:53 +0200 Subject: [PATCH 2/3] sembr tests/crater.md --- src/tests/crater.md | 41 ++++++++++++++++++++++------------------- 1 file changed, 22 insertions(+), 19 deletions(-) diff --git a/src/tests/crater.md b/src/tests/crater.md index 96bb5a4f2..df7e8ef0b 100644 --- a/src/tests/crater.md +++ b/src/tests/crater.md @@ -1,43 +1,46 @@ # Crater [Crater](https://github.com/rust-lang/crater) is a tool for compiling and -running tests for _every_ crate on [crates.io](https://crates.io) (and a few on -GitHub). It is mainly used for checking the extent of breakage when implementing +running tests for _every_ crate on [crates.io](https://crates.io) (and a few on GitHub). +It is mainly used for checking the extent of breakage when implementing potentially breaking changes and ensuring lack of breakage by running beta vs stable compiler versions. ## When to run Crater You should request a Crater run if your PR makes large changes to the compiler -or could cause breakage. If you are unsure, feel free to ask your PR's reviewer. +or could cause breakage. +If you are unsure, feel free to ask your PR's reviewer. ## Requesting Crater Runs The Rust team maintains a few machines that can be used for Crater runs -on the changes introduced by a PR. If your PR needs a Crater run, leave a -comment for the triage team in the PR thread. Please inform the team whether you -require a "check-only" Crater run, a "build only" Crater run, or a -"build-and-test" Crater run. The difference is primarily in time; -if you're not sure, go for the build-and-test run. If +on the changes introduced by a PR. +If your PR needs a Crater run, leave a comment for the triage team in the PR thread. +Please inform the team whether you +require a "check-only" Crater run, a "build only" Crater run, or a "build-and-test" Crater run. +The difference is primarily in time; +if you're not sure, go for the build-and-test run. +If making changes that will only have an effect at compile-time (e.g., implementing a new trait), then you only need a check run. -Your PR will be enqueued by the triage team and the results will be posted when -they are ready. Check runs will take around ~3-4 days, and the other two taking -5-6 days on average. +Your PR will be enqueued by the triage team and the results will be posted when they are ready. +Check runs will take around ~3-4 days, and the other two taking 5-6 days on average. -While Crater is really useful, it is also important to be aware of a few -caveats: +While Crater is really useful, it is also important to be aware of a few caveats: -- Not all code is on crates.io! There is a lot of code in repos on GitHub and - elsewhere. Also, companies may not wish to publish their code. Thus, a - successful Crater run does not mean there will be no +- Not all code is on crates.io! + There is a lot of code in repos on GitHub and elsewhere. + Also, companies may not wish to publish their code. + Thus, a successful Crater run does not mean there will be no breakage; you still need to be careful. -- Crater only runs Linux builds on x86_64. Thus, other architectures and - platforms are not tested. Critically, this includes Windows. +- Crater only runs Linux builds on x86_64. Thus, other architectures and platforms are not tested. + Critically, this includes Windows. -- Many crates are not tested. This could be for a lot of reasons, including that +- Many crates are not tested. + This could be for a lot of reasons, including that the crate doesn't compile any more (e.g. used old nightly features), has broken or flaky tests, requires network access, or other reasons. From 594392fa78e2bef71a5d1cb37856af26c21eea7a Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Sat, 29 Nov 2025 20:00:25 +0200 Subject: [PATCH 3/3] manual formatting improvement --- src/tests/crater.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/src/tests/crater.md b/src/tests/crater.md index df7e8ef0b..beea10aab 100644 --- a/src/tests/crater.md +++ b/src/tests/crater.md @@ -21,9 +21,8 @@ Please inform the team whether you require a "check-only" Crater run, a "build only" Crater run, or a "build-and-test" Crater run. The difference is primarily in time; if you're not sure, go for the build-and-test run. -If -making changes that will only have an effect at compile-time (e.g., implementing -a new trait), then you only need a check run. +If making changes that will only have an effect at compile-time +(e.g., implementing a new trait), then you only need a check run. Your PR will be enqueued by the triage team and the results will be posted when they are ready. Check runs will take around ~3-4 days, and the other two taking 5-6 days on average.