Triage some date references (rust-lang#1293)

Author: JohnTitor

src/doc/rustc-dev-guide/src/crates-io.md

@@ -12,8 +12,8 @@ reasons:
 - The dependency may have transitive dependencies that have one of the above
   problems.
 
-As of <!-- date: 2021-07 --> July 2021, there is no official policy for vetting
-new dependencies to the compiler. Generally, new dependencies are not added 
+As of <!-- date: 2022-02 --> February 2022, there is no official policy for vetting
+new dependencies to the compiler. Generally, new dependencies are not added
 to the compiler unless there is a good reason to do so.
 
 ## Permitted dependencies

src/doc/rustc-dev-guide/src/diagnostics/diagnostic-items.md

@@ -44,7 +44,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. As of August 2021 <!-- date: 2021-08 --> diagnostic items in code are accessed via symbols in
+2. As of <!-- date: 2022-02 --> February 2022, diagnostic items in code are accessed via symbols in
     [`rustc_span::symbol::sym`]. To add your newly created diagnostic item simply open the
     module file and add the name (In this case `Cat`) at the correct point in the list.
 

src/doc/rustc-dev-guide/src/diagnostics/lintstore.md

@@ -17,7 +17,7 @@ First, we have the lint declarations themselves: this is where the name and defa
 other metadata come from. These are normally defined by way of the [`declare_lint!`] macro, which
 boils down to a static with type `&rustc_session::lint::Lint`.
 
-As of <!-- date: 2021-07 --> July 2021, we lint against direct declarations
+As of <!-- date: 2022-02 --> February 2022, we lint against direct declarations
 without the use of the macro today (although this may change in the future, as
 the macro is somewhat unwieldy to add new fields to, like all macros).
 
@@ -56,11 +56,11 @@ internally.
 
 #### Internal lints
 
-These are lints used just by the compiler or plugins like `clippy`. They can be found in 
+These are lints used just by the compiler or plugins like `clippy`. They can be found in
 `rustc_lint::internal`.
 
-An example of such a lint is the check that lint passes are implemented using the 
-`declare_lint_pass!` macro and not by hand. This is accomplished with the 
+An example of such a lint is the check that lint passes are implemented using the
+`declare_lint_pass!` macro and not by hand. This is accomplished with the
 `LINT_PASS_IMPL_WITHOUT_MACRO` lint.
 
 Registration of these lints happens in the [`rustc_lint::register_internals`] function which is
@@ -81,7 +81,7 @@ with internal lints, this happens inside of [`rustc_lint::new_lint_store`].
 This is one of the primary use cases remaining for plugins/drivers. Plugins are given access 
 to the mutable `LintStore` during registration (which happens inside of 
 [`rustc_interface::register_plugins`]) and they can call any functions they need on 
-the `LintStore`, just like rustc code. 
+the `LintStore`, just like rustc code.
 
 Plugins are intended to declare lints with the `plugin` field set to true (e.g., by
 way of the [`declare_tool_lint!`] macro), but this is purely for diagnostics and help text;

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

@@ -157,8 +157,8 @@ no changes added to commit (use "git add" and/or "git commit -a")
 These changes are not changes to files: they are changes to submodules (more on
 this [later](#git-submodules)). To get rid of those, run `git submodule update`
 (or run any `x.py` command, which will automatically update the submodules).
-Note that there is (as of <!-- date: 2021-07 --> July 2021) a [bug][#77620] if you use
-worktrees, submodules, and `x.py` in a commit hook.  If you run into an error
+Note that there is (as of <!-- date: 2022-02 --> February 2022) a [bug][#77620] if you use
+worktrees, submodules, and `x.py` in a commit hook. If you run into an error
 like:
 
 ```

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

@@ -451,8 +451,8 @@ fn main() {
 
 ## Revisions
 
-Certain classes of tests support "revisions" (as of <!-- date: 2021-02 --> February 2021,
-this includes compile-fail, run-fail, and incremental, though
+Certain classes of tests support "revisions" (as of <!-- date: 2022-02 --> February 2022,
+this includes UI, assembly, codegen, incremental, and rustdoc UI tests, though
 incremental tests are somewhat different).
 Revisions allow a single test file to be used for multiple tests.
 This is done by adding a special header at the top of the file: