Add lots of date-check annotations

Also added dates for things that previously said "as of now" or "as of
this writing" and cleaned up a couple of things along the way.

Author: camelid

src/backend/backend-agnostic.md

@@ -2,8 +2,9 @@
 
 <!-- toc -->
 
-As of January 2021, `rustc_codegen_ssa` provides an abstract interface for all backends to
-implement, to allow other codegen backends (e.g. [Cranelift]).
+As of January 2021 <!-- date: 2021-01 -->, `rustc_codegen_ssa` provides an
+abstract interface for all backends to implement, to allow other codegen
+backends (e.g. [Cranelift]).
 
 [Cranelift]: https://github.com/bytecodealliance/wasmtime/tree/HEAD/cranelift
 

src/borrow_check/region_inference/member_constraints.md

@@ -93,15 +93,13 @@ member constraints come in.
 
 ## Choices are always lifetime parameters
 
-At present, the "choice" regions from a member constraint are always
-lifetime parameters from the current function. As of January 2021,
-this falls out from the placement of impl Trait, though in the future
-it may not be the case.
-We take some advantage of this fact, as it simplifies the current
-code. In particular, we don't have to consider a case like `'0 member
-of ['1, 'static]`, in which the value of both `'0` and `'1` are being
-inferred and hence changing. See [rust-lang/rust#61773][#61773] for more
-information.
+At present, the "choice" regions from a member constraint are always lifetime
+parameters from the current function. As of January 2021 <!-- date: 2021-01 -->,
+this falls out from the placement of impl Trait, though in the future it may not
+be the case.  We take some advantage of this fact, as it simplifies the current
+code. In particular, we don't have to consider a case like `'0 member of ['1,
+'static]`, in which the value of both `'0` and `'1` are being inferred and hence
+changing. See [rust-lang/rust#61773][#61773] for more information.
 
 [#61773]: https://github.com/rust-lang/rust/issues/61773
 

src/compiler-src.md

@@ -7,8 +7,9 @@
 > top-level directory has separate directories for the compiler, build-system,
 > std libs, etc, rather than one huge `src/` directory.
 >
-> As of January 2021, the std libs have been moved to `library/` and the crates
-> that make up the `rustc` compiler itself have been moved to `compiler/`
+> As of January 2021 <!-- date: 2021-01 -->, the standard libraries have been
+> moved to `library/` and the crates that make up the `rustc` compiler itself
+> have been moved to `compiler/`.
 
 Now that we have [seen what the compiler does](./overview.md), let's take a
 look at the structure of the contents of the rust-lang/rust repo.
@@ -20,9 +21,9 @@ containing the compiler, the standard libraries (`core`, `alloc`, `std`,
 `proc_macro`, etc), and `rustdoc`, along with the build system and a bunch of
 tools and submodules for building a full Rust distribution.
 
-As of this writing, this structure is gradually undergoing some transformation
-to make it a bit less monolithic and more approachable, especially to
-newcomers.
+As of August 2020 <!-- date: 2020-08 -->, this structure is gradually undergoing
+some transformation to make it a bit less monolithic and more approachable,
+especially to newcomers.
 
 The repository consists of three main directories:
 

src/contributing.md

@@ -410,9 +410,13 @@ Just a few things to keep in mind:
   Aim to provide a reasonable amount of context, possibly including but not limited to:
   - A reason for why the data may be out of date other than "change", as change is a constant across
     the project.
-  - A date the comment was added, e.g. instead of writing _"Currently, ..."_ consider writing
+  - The date the comment was added, e.g. instead of writing _"Currently, ..."_
+    or _"As of now, ..."_, consider writing
     _"As of January 2021, ..."_.
     Try to format the date as `<MONTH> <YEAR>` to ease search.
+  - Additionally, include a machine-readable comment of the form `<!-- date:
+    2021-01 -->` (if the current month is January 2021). We have an automated
+    tool that uses these (in `ci/date-check`).
   - A link to a relevant WG, tracking issue, `rustc` rustdoc page, or similar, that may provide
     further explanation for the change process or a way to verify that the information is not
     outdated.

src/diagnostics.md

@@ -594,9 +594,9 @@ declare_lint! {
 }
 ```
 
-If you need a combination of options that's not supported by the
-`declare_lint!` macro, you can always define your own static with a type of
-`&Lint` but this is (as of January 2021) linted against in the compiler tree.
+If you need a combination of options that's not supported by the `declare_lint!`
+macro, you can always define your own static with a type of `&Lint` but this is
+(as of January 2021 <!-- date: 2021-01 -->) linted against in the compiler tree.
 
 <a id="future-incompatible"></a>
 ####  Guidelines for creating a future incompatibility lint

src/diagnostics/lintstore.md

@@ -17,9 +17,10 @@ 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 January 2021, 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 by example).
+As of January 2021 <!-- date: 2021-01 -->, 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 by
+example).
 
 Lint declarations don't carry any "state" - they are merely global identifers and descriptions of
 lints. We assert at runtime that they are not registered twice (by lint name).

src/git.md

@@ -144,12 +144,12 @@ Changes not staged for commit:
 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 January 2021) a bug if you use worktrees, submodules, and x.py in a commit
-hook.
-If you run into an error like:
+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 January 2021 <!-- date: 2021-01 -->) a bug if you use
+worktrees, submodules, and x.py in a commit hook.  If you run into an error
+like:
 
 ```
 error: failed to read `/home/joshua/rustc-worktree/src/tools/miri/cargo-miri/Cargo.toml`

src/llvm-coverage-instrumentation.md

@@ -221,16 +221,15 @@ properly-configured variables in LLVM IR, according to very specific
 details of the [_LLVM Coverage Mapping Format_][coverage-mapping-format]
 (Version 4).[^llvm-and-covmap-versions]
 
-[^llvm-and-covmap-versions]: The Rust compiler (as of January 2021) supports
-_LLVM Coverage Mapping Format_ Version 4 (the most up-to-date version
-of the format, at the time of this writing) for improved compatibility
-with other LLVM-based compilers (like _Clang_), and to take advantage
-of some format optimizations. Version 4 was introduced in _LLVM 11_,
-which is currently the default LLVM version for Rust. Note that the
-Rust compiler optionally supports some earlier LLVM versions,
-prior to _LLVM 11_. If `rustc` is configured to use an incompatible
-version of LLVM, compiling with `-Z instrument-coverage` will
-generate an error message.
+[^llvm-and-covmap-versions]: The Rust compiler (as of January 2021 <!-- date:
+2021-01 -->) supports _LLVM Coverage Mapping Format_ Version 4 (the most
+up-to-date version of the format, at the time of this writing) for improved
+compatibility with other LLVM-based compilers (like _Clang_), and to take
+advantage of some format optimizations. Version 4 was introduced in _LLVM 11_,
+which is currently the default LLVM version for Rust. Note that the Rust
+compiler optionally supports some earlier LLVM versions, prior to _LLVM 11_. If
+`rustc` is configured to use an incompatible version of LLVM, compiling with `-Z
+instrument-coverage` will generate an error message.
 
 ```rust
 pub fn finalize<'ll, 'tcx>(cx: &CodegenCx<'ll, 'tcx>) {

src/miri.md

@@ -193,12 +193,13 @@ concrete integer.
 
 However, a variable of pointer or reference *type*, such as `*const T` or `&T`,
 does not have to have a pointer *value*: it could be obtaining by casting or
-transmuting an integer to a pointer (as of January 2021 that is hard to do in const eval,
-but eventually `transmute` will be stable as a `const fn`).  And similarly, when
-casting or transmuting a reference to some actual allocation to an integer, we
-end up with a pointer *value* (`Scalar::Ptr`) at integer *type* (`usize`).  This
-is a problem because we cannot meaningfully perform integer operations such as
-division on pointer values.
+transmuting an integer to a pointer (as of January 2021 <!-- date: 2021-01 -->
+that is hard to do in const eval, but eventually `transmute` will be stable as a
+`const fn`).  And similarly, when casting or transmuting a reference to some
+actual allocation to an integer, we end up with a pointer *value*
+(`Scalar::Ptr`) at integer *type* (`usize`).  This is a problem because we
+cannot meaningfully perform integer operations such as division on pointer
+values.
 
 ## Interpretation
 

src/opaque-types-type-alias-impl-trait.md

@@ -14,8 +14,9 @@ This declares an opaque type named `Foo`, of which the only information is that
 it implements `Bar`. Therefore, any of `Bar`'s interface can be used on a `Foo`,
 but nothing else (regardless of whether it implements any other traits).
 
-Since there needs to be a concrete background type, you can (as of January 2021)
-express that type by using the opaque type in a "defining use site".
+Since there needs to be a concrete background type, you can (as of January 2021
+<!-- date: 2021-01 -->) express that type by using the opaque type in a
+"defining use site".
 
 ```rust,ignore
 struct Struct;