dates(diagnostics,tests): refresh annotated dates to Aug 2025; preserve local style

Author: ali90h

src/diagnostics/diagnostic-items.md

@@ -48,7 +48,7 @@ A new diagnostic item can be added with these two steps:
     For the naming conventions of diagnostic items, please refer to
     [*Naming Conventions*](#naming-conventions).
 
-2. <!-- date-check: Feb 2023 -->
+2. <!-- date-check: Aug 2025 -->
    Diagnostic items in code are accessed via symbols in
    [`rustc_span::symbol::sym`].
    To add your newly-created diagnostic item,

src/diagnostics/error-codes.md

@@ -10,7 +10,7 @@ explanation: new error codes must include them. Note that not all _historical_
 The explanations are written in Markdown (see the [CommonMark Spec] for
 specifics around syntax), and all of them are linked in the [`rustc_error_codes`]
 crate. Please read [RFC 1567] for details on how to format and write long error
-codes. As of <!-- date-check --> February 2023, there is an
+codes. As of <!-- date-check --> August 2025, there is an
 effort[^new-explanations] to replace this largely outdated RFC with a new more
 flexible standard.
 

src/diagnostics/lintstore.md

@@ -21,7 +21,7 @@ which boils down to a static with type [`&rustc_lint_defs::Lint`]
 as the macro is somewhat unwieldy to add new fields to,
 like all macros).
 
-As of <!-- date-check --> Aug 2022,
+As of <!-- date-check --> Aug 2025,
 we lint against direct declarations without the use of the macro.
 
 Lint declarations don't carry any "state" - they are merely global identifiers

src/diagnostics/translation.md

@@ -2,12 +2,12 @@
 
 <div class="warning">
 rustc's current diagnostics translation infrastructure (as of
-<!-- date-check --> October 2024
+<!-- date-check --> August 2025
 ) unfortunately causes some friction for compiler contributors, and the current
 infrastructure is mostly pending a redesign that better addresses needs of both
 compiler contributors and translation teams. Note that there is no current
 active redesign proposals (as of
-<!-- date-check --> October 2024
+<!-- date-check --> August 2025
 )!
 
 Please see the tracking issue <https://github.com/rust-lang/rust/issues/132181>

src/tests/ci.md

@@ -22,7 +22,7 @@ jobs](#modifying-ci-jobs).
 
 ## CI workflow
 
-<!-- date-check: Oct 2024 -->
+<!-- date-check: Aug 2025 -->
 
 Our CI is primarily executed on [GitHub Actions], with a single workflow defined
 in [`.github/workflows/ci.yml`], which contains a bunch of steps that are

src/tests/directives.md

@@ -42,7 +42,7 @@ not be exhaustive. Directives can generally be found by browsing the
 
 ### Assembly
 
-<!-- date-check: Oct 2024 -->
+<!-- date-check: Aug 2025 -->
 
 | Directive         | Explanation                   | Supported test suites | Possible values                        |
 |-------------------|-------------------------------|-----------------------|----------------------------------------|
@@ -113,7 +113,7 @@ for more details.
 | `known-bug`                       | No error annotation needed due to known bug                                                                              | `ui`, `crashes`, `incremental`               | Issue number `#123456`                                                                  |
 | `compare-output-by-lines`         | Compare the output by lines, rather than as a single string                                                              | All                                          | N/A                                                                                     |
 
-[^check_stdout]: presently <!-- date-check: Oct 2024 --> this has a weird quirk
+[^check_stdout]: presently <!-- date-check: Aug 2025 --> this has a weird quirk
     where the test binary's stdout and stderr gets concatenated and then
     `error-pattern`s are matched on this combined output, which is ??? slightly
     questionable to say the least.

src/tests/misc.md

@@ -2,7 +2,7 @@
 
 ## `RUSTC_BOOTSTRAP` and stability
 
-<!-- date-check: Nov 2024 -->
+<!-- date-check: Aug 2025 -->
 
 This is a bootstrap/compiler implementation detail, but it can also be useful
 for testing: