Fixes some typos (#1502)
* Fix some typos. Co-authored-by: pierwill <19642016+pierwill@users.noreply.github.com>
This commit is contained in:
parent
43e20eff99
commit
100e801b36
|
|
@ -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 <br> from Crate A appear within a single codegen unit for Crate B. <br> The codegen unit exists even after the post inlining stage.|
|
||||
| Generic `#[inline]` function | - same - |
|
||||
|
||||
|
|
|
|||
|
|
@ -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].
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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 |
|
||||
| -------------------------------- | --------------------------------------------------- | ------------ |
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue