don't refer to the compile-time interpreter as "Miri" (rust-lang#1471)

Author: RalfJung

src/doc/rustc-dev-guide/book.toml

@@ -43,3 +43,4 @@ warning-policy = "error"
 [output.html.redirect]
 "/compiletest.html" = "tests/compiletest.html"
 "/diagnostics/sessiondiagnostic.html" = "diagnostics/diagnostic-structs.html"
+"/miri.html" = "const-eval/interpret.html"

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

@@ -152,7 +152,7 @@
 - [MIR optimizations](./mir/optimizations.md)
 - [Debugging](./mir/debugging.md)
 - [Constant evaluation](./const-eval.md)
-    - [miri const evaluator](./miri.md)
+    - [Interpreter](./const-eval/interpret.md)
 - [Monomorphization](./backend/monomorph.md)
 - [Lowering MIR](./backend/lowering-mir.md)
 - [Code Generation](./backend/codegen.md)

src/doc/rustc-dev-guide/src/appendix/glossary.md

@@ -36,6 +36,7 @@ Term                                                  | Meaning
 <span id="infcx">infcx</span>                  &nbsp; |  The type inference context (`InferCtxt`). (see `rustc_middle::infer`)
 <span id="inf-var">inference variable</span>   &nbsp; |  When doing type or region inference, an "inference variable" is a kind of special type/region that represents what you are trying to infer. Think of X in algebra. For example, if we are trying to infer the type of a variable in a program, we create an inference variable to represent that unknown type.
 <span id="intern">intern</span>                &nbsp; |  Interning refers to storing certain frequently-used constant data, such as strings, and then referring to the data by an identifier (e.g. a `Symbol`) rather than the data itself, to reduce memory usage and number of allocations. See [this chapter](../memory.md) for more info.
+<span id="interpreter">interpreter</span>      &nbsp; |  The heart of const evaluation, running MIR code at compile time. ([see more](../const-eval/interpret.md))
 <span id="intrinsic">intrinsic</span>          &nbsp; |  Intrinsics are special functions that are implemented in the compiler itself but exposed (often unstably) to users. They do magical and dangerous things. (See [`std::intrinsics`](https://doc.rust-lang.org/std/intrinsics/index.html))
 <span id="ir">IR</span>                        &nbsp; |  Short for Intermediate Representation, a general term in compilers. During compilation, the code is transformed from raw source (ASCII text) to various IRs. In Rust, these are primarily HIR, MIR, and LLVM IR. Each IR is well-suited for some set of computations. For example, MIR is well-suited for the borrow checker, and LLVM IR is well-suited for codegen because LLVM accepts it.
 <span id="irlo">IRLO</span>                    &nbsp; |  `IRLO` or `irlo` is sometimes used as an abbreviation for [internals.rust-lang.org](https://internals.rust-lang.org).
@@ -47,7 +48,7 @@ Term                                                  | Meaning
 <span id="llvm">[LLVM]</span>                  &nbsp; |  (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that outputs LLVM IR and use LLVM to compile to all the platforms LLVM supports.
 <span id="memoization">memoization</span>      &nbsp; |  The process of storing the results of (pure) computations (such as pure function calls) to avoid having to repeat them in the future. This is typically a trade-off between execution speed and memory usage.
 <span id="mir">MIR</span>                      &nbsp; |  The Mid-level IR that is created after type-checking for use by borrowck and codegen. ([see more](../mir/index.md))
-<span id="miri">miri</span>                    &nbsp; |  An interpreter for MIR used for constant evaluation. ([see more](../miri.md))
+<span id="miri">Miri</span>                    &nbsp; |  A tool to detect Undefined Behavior in (unsafe) Rust code. ([see more](https://github.com/rust-lang/miri))
 <span id="mono">monomorphization</span>        &nbsp; |  The process of taking generic implementations of types and functions and instantiating them with concrete types. For example, in the code we might have `Vec<T>`, but in the final executable, we will have a copy of the `Vec` code for every concrete type used in the program (e.g. a copy for `Vec<usize>`, a copy for `Vec<MyStruct>`, etc).
 <span id="normalize">normalize</span>          &nbsp; |  A general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/goals-and-clauses.md#normalizeprojection---type).
 <span id="newtype">newtype</span>              &nbsp; |  A wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices.

src/doc/rustc-dev-guide/src/const-eval.md

@@ -77,11 +77,10 @@ As a consequence, all decoding of `ValTree` must happen by matching on the type
 decisions depending on that. The value itself gives no useful information without the type that
 belongs to it.
 
-Other constants get represented as [`ConstValue::Scalar`]
-or [`ConstValue::Slice`] if possible. This means that the `const_eval_*`
-functions cannot be used to create miri-pointers to the evaluated constant.
-If you need the value of a constant inside Miri, you need to directly work with
-[`const_to_op`].
+Other constants get represented as [`ConstValue::Scalar`] or
+[`ConstValue::Slice`] if possible. These values are only useful outside the
+compile-time interpreter. If you need the value of a constant during
+interpretation, you need to directly work with [`const_to_op`].
 
 [`GlobalId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/struct.GlobalId.html
 [`ConstValue::Scalar`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/value/enum.ConstValue.html#variant.Scalar

src/doc/rustc-dev-guide/src/miri.md src/doc/rustc-dev-guide/src/const-eval/interpret.md

@@ -1,14 +1,13 @@
-# Miri
+# Interpreter
 
 <!-- toc -->
 
-The Miri (**MIR** **I**nterpreter) engine is a virtual machine for executing MIR without
-compiling to machine code. It is usually invoked via `tcx.const_eval_*` functions.
-In the following, we will refer to the Miri engine as just "Miri", but note that
-there also is a stand-alone
-[tool called "Miri"](https://github.com/rust-lang/miri/) that is based on the
-engine (sometimes referred to as Miri-the-tool to disambiguate it from the
-engine).
+The interpreter is a virtual machine for executing MIR without compiling to
+machine code. It is usually invoked via `tcx.const_eval_*` functions. The
+interpreter is shared between the compiler (for compile-time function
+evaluation, CTFE) and the tool [Miri](https://github.com/rust-lang/miri/), which
+uses the same virtual machine to detect Undefined Behavior in (unsafe) Rust
+code.
 
 If you start out with a constant:
 
@@ -98,7 +97,7 @@ further queries need to be executed in order to get at something as simple as a
 `usize`.
 
 Future evaluations of the same constants will not actually invoke
-Miri, but just use the cached result.
+the interpreter, but just use the cached result.
 
 [`Operand`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_const_eval/interpret/enum.Operand.html
 [`Immediate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_const_eval/interpret/enum.Immediate.html
@@ -108,7 +107,7 @@ Miri, but just use the cached result.
 
 ## Datastructures
 
-Miri's outside-facing datastructures can be found in
+The interpreter's outside-facing datastructures can be found in
 [rustc_middle/src/mir/interpret](https://github.com/rust-lang/rust/blob/master/compiler/rustc_middle/src/mir/interpret).
 This is mainly the error enum and the [`ConstValue`] and [`Scalar`] types. A
 `ConstValue` can be either `Scalar` (a single `Scalar`, i.e., integer or thin
@@ -124,7 +123,7 @@ in an `Option<u64>` yielding the `Scalar` if possible.
 
 ## Memory
 
-To support any kind of pointers, Miri needs to have a "virtual memory" that the
+To support any kind of pointers, the interpreter needs to have a "virtual memory" that the
 pointers can point to.  This is implemented in the [`Memory`] type.  In the
 simplest model, every global variable, stack variable and every dynamic
 allocation corresponds to an [`Allocation`] in that memory.  (Actually using an
@@ -164,7 +163,7 @@ track of which of its bytes are initialized.
 
 ### Global memory and exotic allocations
 
-`Memory` exists only during the Miri evaluation; it gets destroyed when the
+`Memory` exists only during evaluation; it gets destroyed when the
 final value of the constant is computed.  In case that constant contains any
 pointers, those get "interned" and moved to a global "const eval memory" that is
 part of `TyCtxt`.  These allocations stay around for the remaining computation
@@ -190,10 +189,10 @@ bytes of its value.
 
 ### Pointer values vs Pointer types
 
-One common cause of confusion in Miri is that being a pointer *value* and having
+One common cause of confusion in the interpreter is that being a pointer *value* and having
 a pointer *type* are entirely independent properties.  By "pointer value", we
 refer to a `Scalar::Ptr` containing a `Pointer` and thus pointing somewhere into
-Miri's virtual memory.  This is in contrast to `Scalar::Raw`, which is just some
+the interpreter's virtual memory.  This is in contrast to `Scalar::Raw`, which is just some
 concrete integer.
 
 However, a variable of pointer or reference *type*, such as `*const T` or `&T`,
@@ -214,7 +213,7 @@ that allow accessing the fields of a `ConstValue` (`ByRef` or otherwise). You sh
 never have to access an `Allocation` directly except for translating it to the
 compilation target (at the moment just LLVM).
 
-Miri starts by creating a virtual stack frame for the current constant that is
+The interpreter starts by creating a virtual stack frame for the current constant that is
 being evaluated. There's essentially no difference between a constant and a
 function with no arguments, except that constants do not allow local (named)
 variables at the time of writing this guide.
@@ -231,7 +230,7 @@ The frames are just a `Vec<Frame>`, there's no way to actually refer to a
 `Frame`'s memory even if horrible shenanigans are done via unsafe code. The only
 memory that can be referred to are `Allocation`s.
 
-Miri now calls the `step` method (in
+The interpreter now calls the `step` method (in
 [rustc_const_eval/src/interpret/step.rs](https://github.com/rust-lang/rust/blob/master/compiler/rustc_const_eval/src/interpret/step.rs)
 ) until it either returns an error or has no further statements to execute. Each
 statement will now initialize or modify the locals or the virtual memory