about summary refs log tree commit diff
diff options
context:
space:
mode:
authorNadrieril <Nadrieril@users.noreply.github.com>2020-12-22 06:09:54 +0000
committerNadrieril <nadrieril+git@gmail.com>2020-12-22 15:20:24 +0000
commit85fdb34d3acf631d36d493a65d45b7bd7571e55d (patch)
tree39fd144d6722378f77c5bbda793dd4da3a7d9141
parent1c176d1150db4dbbc922c56abbc2cf0e8cf9abc1 (diff)
downloadrust-85fdb34d3acf631d36d493a65d45b7bd7571e55d.tar.gz
rust-85fdb34d3acf631d36d493a65d45b7bd7571e55d.zip
Apply suggestions from code review
Co-authored-by: varkor <github@varkor.com>
-rw-r--r--compiler/rustc_mir_build/src/thir/pattern/deconstruct_pat.rs10
-rw-r--r--compiler/rustc_mir_build/src/thir/pattern/usefulness.rs19
2 files changed, 15 insertions, 14 deletions
diff --git a/compiler/rustc_mir_build/src/thir/pattern/deconstruct_pat.rs b/compiler/rustc_mir_build/src/thir/pattern/deconstruct_pat.rs
index 357735d6c16..d79dd97a69a 100644
--- a/compiler/rustc_mir_build/src/thir/pattern/deconstruct_pat.rs
+++ b/compiler/rustc_mir_build/src/thir/pattern/deconstruct_pat.rs
@@ -451,7 +451,7 @@ impl Slice {
 ///
 /// A slice pattern `[x, .., y]` behaves like the infinite or-pattern `[x, y] | [x, _, y] | [x, _,
 /// _, y] | ...`. The corresponding value constructors are fixed-length array constructors above a
-/// given minimum length. We obviously can't list all of this infinity of constructors. Thankfully,
+/// given minimum length. We obviously can't list this infinitude of constructors. Thankfully,
 /// it turns out that for each finite set of slice patterns, all sufficiently large array lengths
 /// are equivalent.
 ///
@@ -491,7 +491,7 @@ impl Slice {
 /// middle. This means that the set of witnesses for length `l >= 5` if equivalent to the set for
 /// any other `l' >= 5`: simply add or remove wildcards in the middle to convert between them.
 ///
-/// This applies to any set of slice patterns: there will be a length `L` above which all length
+/// This applies to any set of slice patterns: there will be a length `L` above which all lengths
 /// behave the same. This is exactly what we need for constructor splitting. Therefore a
 /// variable-length slice can be split into a variable-length slice of minimal length `L`, and many
 /// fixed-length slices of lengths `< L`.
@@ -736,8 +736,8 @@ impl<'tcx> Constructor<'tcx> {
             // ranges check.
             IntRange(ctor_range) if !ctor_range.is_singleton() => {
                 let mut split_range = SplitIntRange::new(ctor_range.clone());
-                let intranges = ctors.filter_map(|ctor| ctor.as_int_range());
-                split_range.split(intranges.cloned());
+                let int_ranges = ctors.filter_map(|ctor| ctor.as_int_range());
+                split_range.split(int_ranges.cloned());
                 split_range.iter().map(IntRange).collect()
             }
             &Slice(Slice { kind: VarLen(self_prefix, self_suffix), array_len }) => {
@@ -1080,7 +1080,7 @@ impl<'p, 'tcx> FilteredField<'p, 'tcx> {
 ///
 /// If a private or `non_exhaustive` field is uninhabited, the code mustn't observe that it is
 /// uninhabited. For that, we filter these fields out of the matrix. This is handled automatically
-/// in `Fields`. This filtering is uncommon in practice, because uninhabited fields are rare used,
+/// in `Fields`. This filtering is uncommon in practice, because uninhabited fields are rarely used,
 /// so we avoid it when possible to preserve performance.
 #[derive(Debug, Clone)]
 pub(super) enum Fields<'p, 'tcx> {
diff --git a/compiler/rustc_mir_build/src/thir/pattern/usefulness.rs b/compiler/rustc_mir_build/src/thir/pattern/usefulness.rs
index 6c40abf3f20..803ffc0885e 100644
--- a/compiler/rustc_mir_build/src/thir/pattern/usefulness.rs
+++ b/compiler/rustc_mir_build/src/thir/pattern/usefulness.rs
@@ -19,7 +19,7 @@
 //!
 //! The algorithm implemented here is a modified version of the one described in [this
 //! paper](http://moscova.inria.fr/~maranget/papers/warn/index.html). We have however generalized
-//! it to accomodate the variety of patterns that rust supports. We thus explain our version here,
+//! it to accommodate the variety of patterns that Rust supports. We thus explain our version here,
 //! without being as rigorous.
 //!
 //!
@@ -27,13 +27,13 @@
 //!
 //! The core of the algorithm is the notion of "usefulness". A pattern `q` is said to be *useful*
 //! relative to another pattern `p` of the same type if there is a value that is matched by `q` and
-//! not matched by `p`. This generalizes to many `p`s: `q` is useful wrt a list of patterns `p_1 ..
-//! p_n` if there is a value that is matched by `q` and by none of the `p_i`. We write
+//! not matched by `p`. This generalizes to many `p`s: `q` is useful w.r.t. a list of patterns
+//! `p_1 .. p_n` if there is a value that is matched by `q` and by none of the `p_i`. We write
 //! `usefulness(p_1 .. p_n, q)` for a function that returns a list of such values. The aim of this
 //! file is to compute it efficiently.
 //!
 //! This is enough to compute reachability: a pattern in a `match` expression is reachable iff it
-//! is useful wrt the patterns above it:
+//! is useful w.r.t. the patterns above it:
 //! ```rust
 //! match x {
 //!     Some(_) => ...,
@@ -44,8 +44,8 @@
 //! ```
 //!
 //! This is also enough to compute exhaustiveness: a match is exhaustive iff the wildcard `_`
-//! pattern is _not_ useful wrt the patterns in the match. The values returned by `usefulness` are
-//! used to tell the user which values are missing.
+//! pattern is _not_ useful w.r.t. the patterns in the match. The values returned by `usefulness`
+//! are used to tell the user which values are missing.
 //! ```rust
 //! match x {
 //!     Some(0) => ...,
@@ -102,7 +102,7 @@
 //!
 //! Note: this constructors/fields distinction may not straightforwardly apply to every Rust type.
 //! For example a value of type `Rc<u64>` can't be deconstructed that way, and `&str` has an
-//! infinity of constructors. There are also subtleties with visibility of fields and
+//! infinitude of constructors. There are also subtleties with visibility of fields and
 //! uninhabitedness and various other things. The constructors idea can be extended to handle most
 //! of these subtleties though; caveats are documented where relevant throughout the code.
 //!
@@ -184,7 +184,8 @@
 //!
 //!   `specialize(c, p0 | p1) := specialize(c, p0) ++ specialize(c, p1)`
 //!
-//! - We treat the other pattern constructors lik big or-patterns of all the possibilities:
+//! - We treat the other pattern constructors as if they were a large or-pattern of all the
+//!   possibilities:
 //!
 //!   `specialize(c, _) := specialize(c, Variant1(_) | Variant2(_, _) | ...)`
 //!
@@ -193,7 +194,7 @@
 //!   `specialize(c, [p0, .., p1]) := specialize(c, [p0, p1] | [p0, _, p1] | [p0, _, _, p1] | ...)`
 //!
 //! - If `c` is a pattern-only constructor, `specialize` is defined on a case-by-case basis. See
-//!   the discussion abount constructor splitting in [`super::deconstruct_pat`].
+//!   the discussion about constructor splitting in [`super::deconstruct_pat`].
 //!
 //!
 //! We then extend this function to work with pattern-stacks as input, by acting on the first