Fixes #924 Add context to dated information

Author: igaray

src/SUMMARY.md

@@ -107,7 +107,6 @@
         - [Lowering to logic](./traits/lowering-to-logic.md)
         - [Goals and clauses](./traits/goals-and-clauses.md)
         - [Canonical queries](./traits/canonical-queries.md)
-        - [Lowering module in rustc](./traits/lowering-module.md)
 - [Type checking](./type-checking.md)
     - [Method Lookup](./method-lookup.md)
     - [Variance](./variance.md)

src/about-this-guide.md

@@ -30,10 +30,25 @@ There are six parts to this guide:
 [p5]: ./part-5-intro.md
 [app]: ./appendix/background.md
 
-The Guide itself is of course open-source as well, and the sources can
-be found at the [GitHub repository]. If you find any mistakes in the
-guide, please file an issue about it, or even better, open a PR
-with a correction!
+### Constant change
+
+Keep in mind that `rustc` is a real production-quality product, being worked upon continuously by a
+sizeable set of contributors.
+As such, it has its fair share of codebase churn and technical debt.
+In addition, many of the ideas discussed throughout this guide are idealized designs that are not
+fully realized yet.
+All this makes keeping this guide completely up to date on everything very hard!
+
+The Guide itself is of course open-source as well, and the sources can be found at the
+[GitHub repository].
+If you find any mistakes in the guide, please file an issue about it, or even better, open a PR with
+a correction!
+
+If you do contribute to the guide, please see the corresponding
+[subsection on writing documentation](contributing.md#writing-documentation).
+
+> “‘All conditioned things are impermanent’ — when one sees this with wisdom, one turns away from
+> suffering.” _The Dhammapada, verse 277_
 
 ## Other places to find information
 

src/backend/backend-agnostic.md

@@ -1,8 +1,7 @@
 # Backend Agnostic Codegen
 
-In the future, it would be nice to allow other codegen backends (e.g.
-[Cranelift]). To this end, `rustc_codegen_ssa` provides an
-abstract interface for all backends to implement.
+As of January 2021, `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

@@ -92,8 +92,9 @@ 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. This falls out from the
-placement of impl Trait, though in the future it may not be the case.
+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

src/contributing.md

@@ -407,6 +407,11 @@ repo][rdgrepo]. The issue tracker in that repo is also a great way to find
 things that need doing. There are issues for beginners and advanced compiler
 devs alike!
 
+When contributing text to the guide, please contextualize the information in some time period.
+E.g. instead of writing _"Currently, ..."_, or _"In the future, ..."_, consider writing
+_"As of January 2021, ..."_.
+
+
 [rdg]: https://rustc-dev-guide.rust-lang.org/
 [rdgrepo]: https://github.com/rust-lang/rustc-dev-guide
 

src/diagnostics/lintstore.md

@@ -15,9 +15,11 @@ Unfortunately, a lot of the documentation we have refers to both of these as jus
 
 First, we have the lint declarations themselves: this is where the name and default lint level and
 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`. We lint against direct declarations
-without the use of the macro today (though this may change in the future, as the macro is somewhat
-unwieldy to add new fields to, like all macros by example).
+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).
 
 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/overview.md

@@ -15,7 +15,6 @@ So first, let's look at what the compiler does to your code. For now, we will
 avoid mentioning how the compiler implements these steps except as needed;
 we'll talk about that later.
 
-
 - The compile process begins when a user writes a Rust source program in text
   and invokes the `rustc` compiler on it. The work that the compiler needs to
   perform is defined by command-line options. For example, it is possible to
@@ -159,17 +158,6 @@ satisfy/optimize for. For example,
 So, as you read through the rest of the guide, keep these things in mind. They
 will often inform decisions that we make.
 
-### Constant change
-
-Keep in mind that `rustc` is a real production-quality product.
-As such, it has its fair share of codebase churn and technical debt. A lot of
-the designs discussed throughout this guide are idealized designs that are not
-fully realized yet. And things keep changing so that it is hard to keep this
-guide completely up to date on everything!
-
-The compiler definitely has rough edges, but because of its design it is able
-to keep up with the requirements above.
-
 ### Intermediate representations
 
 As with most compilers, `rustc` uses some intermediate representations (IRs) to

src/parallel-rustc.md

@@ -1,9 +1,10 @@
 # Parallel Compilation
 
 Most of the compiler is not parallel. This represents an opportunity for
-improving compiler performance. Much effort has been put into parallelizing
-`rustc`, but it is still pretty early days for this work. There is a lot of
-design and correctness work that needs to be done.
+improving compiler performance.
+
+As of January 2021, work on explicitly parallelizing the compiler has stalled.
+There is a lot of design and correctness work that needs to be done.
 
 One can try out the current parallel compiler work by enabling it in the
 `config.toml`.

src/profiling.md

@@ -90,5 +90,5 @@ The llvm-lines output is affected by several options.
 
 MIR optimizations have little impact. Compared to the default `RUSTFLAGS="-Z mir-opt-level=1"`,
 level 0 adds 0.3GB and level 2 removes 0.2GB.
-Inlining currently only happens in LLVM, but this might change in the future.
+As of January 2021, inlining currently only happens in LLVM but this might change in the future.
 

src/queries/profiling.md

@@ -86,8 +86,8 @@ The trace of the queries has a formal structure; see
 We style this formal structure as follows:
 
 - **Timed passes:** Green boxes, when present (via `-Z time-passes`), represent
-  _timed passes_ in the compiler. In future versions, these passes may be
-  replaced by queries, explained below.
+  _timed passes_ in the compiler. As of January 2021 these passes are not queries, but may be
+  replaced by queries in future versions.
 - **Labels:** Some green and red boxes are labeled with text. Where they are
   present, the labels give the following information:
   - The [query's _provider_](#queries), sans its _key_ and its _result_, which

src/queries/query-evaluation-model-in-detail.md

@@ -75,11 +75,11 @@ When the query context is created, it is still empty: No queries have been
 executed, no results are cached. But the context already provides access to
 "input" data, i.e. pieces of immutable data that were computed before the
 context was created and that queries can access to do their computations.
-Currently this input data consists mainly of the HIR map, upstream crate
-metadata, and the command-line
-options the compiler was invoked with. In the future, inputs will just consist
-of command-line options and a list of source files -- the HIR map will itself
-be provided by a query which processes these source files.
+
+As of January 2021, this input data consists mainly of the HIR map, upstream crate metadata, and the
+command-line options the compiler was invoked with; but in the future inputs will just consist of
+command-line options and a list of source files -- the HIR map will itself be provided by a query
+which processes these source files.
 
 Without inputs, queries would live in a void without anything to compute their
 result from (remember, query providers only have access to other queries and

src/salsa.md

@@ -7,8 +7,10 @@ want to watch [Salsa In More
 Depth](https://www.youtube.com/watch?v=i_IhACacPRY), also by Niko
 Matsakis.
 
-> Salsa is not used directly in rustc, but it is used extensively for
-> rust-analyzer and may be integrated into the compiler in the future.
+> As of January 2021, although Salsa is inspired by (among other things9 rustc's query system,
+> it is not used directly in rustc.
+> It _is_ used in chalk, and extensively in `rust-analyzer`, but there no medium or long-term
+> concrete plans to integrate it into the compiler.
 
 ## What is Salsa?
 

src/the-parser.md

@@ -1,7 +1,7 @@
 # Lexing and Parsing
 
-> The parser and lexer are currently undergoing a lot of refactoring, so parts
-> of this chapter may be out of date.
+As of January 2021, the lexer and parser are undergoing refactoring to allow
+extracting them into libraries.
 
 The very first thing the compiler does is take the program (in Unicode
 characters) and turn it into something the compiler can work with more

src/traits/lowering-module.md

@@ -118,7 +118,7 @@ the obligation contains unbound inference variables.
 
 The subroutines that decide whether a particular impl/where-clause/etc
 applies to a particular obligation are collectively referred to as the
-process of _matching_. At the moment, this amounts to
+process of _matching_. As of January 2021, this amounts to
 unifying the `Self` types, but in the future we may also recursively
 consider some of the nested obligations, in the case of an impl.