diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 6b3ec419..4eba27fc 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -87,7 +87,7 @@ Term | Meaning uninhabited type   | A type which has _no_ values. This is not the same as a ZST, which has exactly 1 value. An example of an uninhabited type is `enum Foo {}`, which has no variants, and so, can never be created. The compiler can treat code that deals with uninhabited types as dead code, since there is no such value to be manipulated. `!` (the never type) is an uninhabited type. Uninhabited types are also called "empty types". upvar   | A variable captured by a closure from outside the closure. variance   | Determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec` is a subtype `Vec` because `Vec` is *covariant* in its generic parameter. See [the background chapter](./background.md#variance) for a more general explanation. See the [variance chapter](../variance.md) for an explanation of how type checking handles variance. -variant index   | In an enum, identifies a variant by assigning them indices starting at 0. This is purely internal and not to be confused with the ["discrimiant"](#discriminant) which can be overwritten by the user (e.g. `enum Bool { True = 42, False = 0 }`). +variant index   | In an enum, identifies a variant by assigning them indices starting at 0. This is purely internal and not to be confused with the ["discriminant"](#discriminant) which can be overwritten by the user (e.g. `enum Bool { True = 42, False = 0 }`). wide pointer   | A pointer with additional metadata. See "fat pointer" for more. ZST   | Zero-Sized Type. A type whose values have size 0 bytes. Since `2^0 = 1`, such types can have exactly one value. For example, `()` (unit) is a ZST. `struct Foo;` is also a ZST. The compiler can do some nice optimizations around ZSTs. diff --git a/src/backend/monomorph.md b/src/backend/monomorph.md index 0dc80543..a2918b60 100644 --- a/src/backend/monomorph.md +++ b/src/backend/monomorph.md @@ -71,7 +71,7 @@ or more modules in Crate B. | - | - | | Non-generic function | Crate A function doesn't appear in any codegen units of Crate B | | Non-generic `#[inline]` function | Crate A function appears with in a single CGU of Crate B, and exists even after post-inlining stage| -| Generic function | Regardless of inlining, all monoporphized (specialized) functions
from Crate A appear within a single codegen unit for Crate B.
The codegen unit exists even after the post inlining stage.| +| Generic function | Regardless of inlining, all monomorphized (specialized) functions
from Crate A appear within a single codegen unit for Crate B.
The codegen unit exists even after the post inlining stage.| | Generic `#[inline]` function | - same - | For more details about the partitioner read the module level [documentation]. diff --git a/src/diagnostics/lintstore.md b/src/diagnostics/lintstore.md index d2796c07..b544d2b6 100644 --- a/src/diagnostics/lintstore.md +++ b/src/diagnostics/lintstore.md @@ -21,7 +21,7 @@ As of July 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). -Lint declarations don't carry any "state" - they are merely global identifers and descriptions of +Lint declarations don't carry any "state" - they are merely global identifiers and descriptions of lints. We assert at runtime that they are not registered twice (by lint name). Lint passes are the meat of any lint. Notably, there is not a one-to-one relationship between diff --git a/src/early-late-bound.md b/src/early-late-bound.md index 4178a4af..29b2136b 100644 --- a/src/early-late-bound.md +++ b/src/early-late-bound.md @@ -24,7 +24,7 @@ of type `for fn(T)`, we would need a single function pointer that can be used for a parameter of any type, but in Rust we generate customized code for each parameter type. -One consequence of this asymmetry is a weird split in how we represesent some +One consequence of this asymmetry is a weird split in how we represent some generic types: _early-_ and _late-_ bound parameters. Basically, if we cannot represent a type (e.g. a universally quantified type), we have to bind it _early_ so that the unrepresentable type is never around. diff --git a/src/git.md b/src/git.md index ac03a3c0..40f846d6 100644 --- a/src/git.md +++ b/src/git.md @@ -408,7 +408,7 @@ nothing to commit, working tree clean ``` As far as git is concerned, you are no longer in the `rust` repo, but in the `miri` repo. -You will notice that we are in "detatched HEAD" state, i.e. not on a branch but on a +You will notice that we are in "detached HEAD" state, i.e. not on a branch but on a particular commit. This is because, like any dependency, we want to be able to control which version to use. diff --git a/src/llvm-coverage-instrumentation.md b/src/llvm-coverage-instrumentation.md index 3dd565b5..4a0f53bf 100644 --- a/src/llvm-coverage-instrumentation.md +++ b/src/llvm-coverage-instrumentation.md @@ -453,7 +453,7 @@ The nodes contain information in sections: its `BasicCoverageBlockData`). 2. The first content section shows the assigned `Counter` or `Expression` for each contiguous section of code. (There may be more than one `Expression` - incremented by the same `Counter` for discontiguous sections of code + incremented by the same `Counter` for noncontiguous sections of code representing the same sequential actions.) Note the code is represented by the line and column ranges (for example: `52:28-52:33`, representing the original source line 52, for columns 28-33). These are followed by the MIR diff --git a/src/macro-expansion.md b/src/macro-expansion.md index ce828528..2f42ad9b 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -585,7 +585,7 @@ syntactic sugar and are allowed to be in namespaces. ## Procedural Macros -Precedural macros are also expanded during parsing, as mentioned above. +Procedural macros are also expanded during parsing, as mentioned above. However, they use a rather different mechanism. Rather than having a parser in the compiler, procedural macros are implemented as custom, third-party crates. The compiler will compile the proc macro crate and specially annotated diff --git a/src/mir/debugging.md b/src/mir/debugging.md index 84030b13..3da17785 100644 --- a/src/mir/debugging.md +++ b/src/mir/debugging.md @@ -12,7 +12,7 @@ control-flow graph spans associated with MIR elements (including mouse-over actions to reveal elements obscured by overlaps, and tooltips to view the MIR statements). This flag takes an optional value: `statement` (the default), `terminator`, or -`block`, to generate span highlights with different levels of granulatity. +`block`, to generate span highlights with different levels of granularity. `-Z dump-mir=F` is a handy compiler options that will let you view the MIR for each function at each stage of compilation. `-Z dump-mir` takes a **filter** `F` diff --git a/src/mir/index.md b/src/mir/index.md index d3bceae4..0c00928c 100644 --- a/src/mir/index.md +++ b/src/mir/index.md @@ -54,7 +54,7 @@ This section introduces the key concepts of MIR, summarized here: - **Operands:** the arguments to an rvalue, which can either be a constant (like `22`) or a place (like `_1`). -You can get a feeling for how MIR is structed by translating simple +You can get a feeling for how MIR is constructed by translating simple programs into MIR and reading the pretty printed output. In fact, the playground makes this easy, since it supplies a MIR button that will show you the MIR for your program. Try putting this program into play diff --git a/src/miri.md b/src/miri.md index 50bbb4b5..dd54f654 100644 --- a/src/miri.md +++ b/src/miri.md @@ -119,7 +119,7 @@ allocation. These allocations can be accessed via the methods on see [the next section](#memory) for more on that. If you are expecting a numeric result, you can use `eval_usize` (panics on -anything that can't be representad as a `u64`) or `try_eval_usize` which results +anything that can't be represented as a `u64`) or `try_eval_usize` which results in an `Option` yielding the `Scalar` if possible. ## Memory diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md index 85f6601a..af30b473 100644 --- a/src/profiling/with_perf.md +++ b/src/profiling/with_perf.md @@ -253,7 +253,7 @@ the regular expression matched. ### Example: Where does MIR borrowck spend its time? -Often we want to do a more "explorational" queries. Like, we know that +Often we want to do more "explorational" queries. Like, we know that MIR borrowck is 29% of the time, but where does that time get spent? For that, the `--tree-callees` option is often the best tool. You usually also want to give `--tree-min-percent` or diff --git a/src/tests/running.md b/src/tests/running.md index ca5b7f3a..19925fe2 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -194,7 +194,7 @@ The possible compare modes are: * split-dwarf * split-dwarf-single -Note that compare modes are seperate to [revisions](./adding.html#revisions). +Note that compare modes are separate to [revisions](./adding.html#revisions). All revisions are tested when running `./x.py test src/test/ui`, however compare-modes must be manually run individually via the `--compare-mode` flag. diff --git a/src/tracing.md b/src/tracing.md index 422d94c5..63d68e54 100644 --- a/src/tracing.md +++ b/src/tracing.md @@ -176,7 +176,7 @@ here. There is no perfect balance to hit here, and is left to the reviewer's discretion to decide whether to let you leave `debug!` statements in or whether to ask you to remove them before merging. -It may be preferrable to use `trace!` over `debug!` for very noisy logs. +It may be preferable to use `trace!` over `debug!` for very noisy logs. A loosely followed convention is to use `#[instrument(level = "debug")]` ([also see the attribute's documentation](https://docs.rs/tracing-attributes/0.1.17/tracing_attributes/attr.instrument.html)) @@ -201,4 +201,4 @@ This means that you should not put anything too expensive or likely to crash there - that would annoy anyone who wants to use logging for that module. No-one will know it until someone tries to use logging to find *another* bug. -[`tracing`]: https://docs.rs/tracing \ No newline at end of file +[`tracing`]: https://docs.rs/tracing diff --git a/src/ty.md b/src/ty.md index 9ee2ccfe..87d653a7 100644 --- a/src/ty.md +++ b/src/ty.md @@ -312,7 +312,7 @@ delaying a redundant span bug. Recall that we represent a generic struct with `(AdtDef, substs)`. So why bother with this scheme? -Well, the alternate way we could have choosen to represent types would be to always create a new, +Well, the alternate way we could have chosen to represent types would be to always create a new, fully-substituted form of the `AdtDef` where all the types are already substituted. This seems like less of a hassle. However, the `(AdtDef, substs)` scheme has some advantages over this.