From 1adbc51a7b728018cbfcdd2288a632ac12463e6f Mon Sep 17 00:00:00 2001 From: jonathanCogan Date: Wed, 2 Nov 2022 01:07:30 -0700 Subject: [PATCH 1/3] Fix some typos. --- src/backend/monomorph.md | 2 +- src/macro-expansion.md | 6 +++--- src/mir/dataflow.md | 2 +- src/mir/drop-elaboration.md | 2 +- src/mir/passes.md | 4 ++-- src/parallel-rustc.md | 2 +- src/ty-fold.md | 2 +- 7 files changed, 10 insertions(+), 10 deletions(-) diff --git a/src/backend/monomorph.md b/src/backend/monomorph.md index 416151ca9..21a788203 100644 --- a/src/backend/monomorph.md +++ b/src/backend/monomorph.md @@ -70,7 +70,7 @@ or more modules in Crate B. | Crate A function | Behavior | | - | - | | 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| +| Non-generic `#[inline]` function | Crate A function appears within a single CGU of Crate B, and exists even after 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 - | diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 156df8d5f..7be7fb121 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -149,9 +149,9 @@ macros are implemented in [`rustc_builtin_macros`], along with some other early code generation facilities like injection of standard library imports or generation of test harness. There are some additional helpers for building their AST fragments in [`rustc_expand::build`][reb]. Eager expansion generally -performs a subset of the things that lazy (normal) expansion. It is done by +performs a subset of the things that lazy (normal) expansion does. It is done by invoking [`fully_expand_fragment`][fef] on only part of a crate (as opposed to -whole crate, like we normally do). +the whole crate, like we normally do). ### Other Data Structures @@ -532,7 +532,7 @@ three cases has occurred: - Failure: the token stream does not match `matcher`. This results in an error message such as "No rule expected token _blah_". - Error: some fatal error has occurred _in the parser_. For example, this - happens if there are more than one pattern match, since that indicates + happens if there is more than one pattern match, since that indicates the macro is ambiguous. The full interface is defined [here][code_parse_int]. diff --git a/src/mir/dataflow.md b/src/mir/dataflow.md index ce4a86a23..15bfd6aed 100644 --- a/src/mir/dataflow.md +++ b/src/mir/dataflow.md @@ -61,7 +61,7 @@ slower as a result. All implementers of `GenKillAnalysis` also implement ### Transfer Functions and Effects The dataflow framework in `rustc` allows each statement (and terminator) inside -a basic block define its own transfer function. For brevity, these +a basic block to define its own transfer function. For brevity, these individual transfer functions are known as "effects". Each effect is applied successively in dataflow order, and together they define the transfer function for the entire basic block. It's also possible to define an effect for diff --git a/src/mir/drop-elaboration.md b/src/mir/drop-elaboration.md index 20b92cc45..0869e0e3d 100644 --- a/src/mir/drop-elaboration.md +++ b/src/mir/drop-elaboration.md @@ -111,7 +111,7 @@ a few optimizations: - Only paths that are the target of a `Drop` (or have the target as a prefix) need drop flags. -- Some variables are known to initialized (or uninitialized) when they are +- Some variables are known to be initialized (or uninitialized) when they are dropped. These do not need drop flags. - If a set of paths are only dropped or moved from via a shared prefix, those paths can share a single drop flag. diff --git a/src/mir/passes.md b/src/mir/passes.md index 5528b7762..67b5eecdd 100644 --- a/src/mir/passes.md +++ b/src/mir/passes.md @@ -36,7 +36,7 @@ keep things efficient). A good example of a basic MIR pass is [`NoLandingPads`], which walks the MIR and removes all edges that are due to unwinding – this is used when configured with `panic=abort`, which never unwinds. As you -can see from its source, a MIR pass is defined by first defining a +can see from its source, an MIR pass is defined by first defining a dummy type, a struct with no fields, something like: ```rust @@ -49,7 +49,7 @@ this pass into the appropriate list of passes found in a query like should go into the `optimized_mir` list.) If you are writing a pass, there's a good chance that you are going to -want to use a [MIR visitor]. MIR visitors are a handy way to walk all +want to use an [MIR visitor]. MIR visitors are a handy way to walk all the parts of the MIR, either to search for something or to make small edits. diff --git a/src/parallel-rustc.md b/src/parallel-rustc.md index e93f51dbb..a672e5fd5 100644 --- a/src/parallel-rustc.md +++ b/src/parallel-rustc.md @@ -26,7 +26,7 @@ occurs in the `rustc_codegen_ssa::base` module. The underlying thread-safe data-structures used in the parallel compiler can be found in the `rustc_data_structures::sync` module. These data structures -are implemented diferently depending on whether `parallel-compiler` is true. +are implemented differently depending on whether `parallel-compiler` is true. | data structure | parallel | non-parallel | | -------------------------------- | --------------------------------------------------- | ------------ | diff --git a/src/ty-fold.md b/src/ty-fold.md index c390597f9..dd76b80d4 100644 --- a/src/ty-fold.md +++ b/src/ty-fold.md @@ -17,7 +17,7 @@ and For example, the `TypeFolder` trait has a method [`fold_ty`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/fold/trait.TypeFolder.html#method.fold_ty) -that takes a type as input a type and returns a new type as a result. `TypeFoldable` invokes the +that takes a type as input and returns a new type as a result. `TypeFoldable` invokes the `TypeFolder` `fold_foo` methods on itself, giving the `TypeFolder` access to its contents (the types, regions, etc that are contained within). From 83dd99fcee81c210b15dad5b8760c7eade8f6248 Mon Sep 17 00:00:00 2001 From: pierwill <19642016+pierwill@users.noreply.github.com> Date: Wed, 2 Nov 2022 13:10:17 -0500 Subject: [PATCH 2/3] Update src/mir/passes.md --- src/mir/passes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mir/passes.md b/src/mir/passes.md index 67b5eecdd..777ad9cf2 100644 --- a/src/mir/passes.md +++ b/src/mir/passes.md @@ -36,7 +36,7 @@ keep things efficient). A good example of a basic MIR pass is [`NoLandingPads`], which walks the MIR and removes all edges that are due to unwinding – this is used when configured with `panic=abort`, which never unwinds. As you -can see from its source, an MIR pass is defined by first defining a +can see from its source, a MIR pass is defined by first defining a dummy type, a struct with no fields, something like: ```rust From 180986df0e2596bcc30aa435f7e63a3752b978b5 Mon Sep 17 00:00:00 2001 From: pierwill <19642016+pierwill@users.noreply.github.com> Date: Wed, 2 Nov 2022 13:10:22 -0500 Subject: [PATCH 3/3] Update src/mir/passes.md --- src/mir/passes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mir/passes.md b/src/mir/passes.md index 777ad9cf2..5528b7762 100644 --- a/src/mir/passes.md +++ b/src/mir/passes.md @@ -49,7 +49,7 @@ this pass into the appropriate list of passes found in a query like should go into the `optimized_mir` list.) If you are writing a pass, there's a good chance that you are going to -want to use an [MIR visitor]. MIR visitors are a handy way to walk all +want to use a [MIR visitor]. MIR visitors are a handy way to walk all the parts of the MIR, either to search for something or to make small edits.