bjoernager/rust
bjoernager/rust
1
Fork 0
Code Activity

Rollup merge of #95497 - nyurik:compiler-spell-comments, r=compiler-errors

Browse source 
Spellchecking compiler comments

This PR cleans up the rest of the spelling mistakes in the compiler comments. This PR does not change any literal or code spelling issues.
This commit is contained in:
Dylan DPC 2022-03-31 04:57:28 +02:00 • committed by GitHub
commit 1b7d6dbd30
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
111 changed files with 164 additions and 164 deletions
Download patch file Download diff file Expand all files Collapse all files

2
compiler/rustc_mir_build/src/build/matches/mod.rs
View file

@ -444,7 +444,7 @@ impl<'a, 'tcx> Builder<'a, 'tcx> {
// we lower the guard.
let target_block = self.cfg.start_new_block();
let mut schedule_drops = true;
// We keep a stack of all of the bindings and type asciptions
// We keep a stack of all of the bindings and type ascriptions
// from the parent candidates that we visit, that also need to
// be bound for each candidate.
traverse_candidate(

4
compiler/rustc_mir_build/src/build/scope.rs
View file

@ -567,7 +567,7 @@ impl<'a, 'tcx> Builder<'a, 'tcx> {
let tcx = self.tcx;
if let LintLevel::Explicit(current_hir_id) = lint_level {
// Use `maybe_lint_level_root_bounded` with `root_lint_level` as a bound
// to avoid adding Hir dependences on our parents.
// to avoid adding Hir dependencies on our parents.
// We estimate the true lint roots here to avoid creating a lot of source scopes.
let parent_root = tcx.maybe_lint_level_root_bounded(
@ -965,7 +965,7 @@ impl<'a, 'tcx> Builder<'a, 'tcx> {
/// However, `_X` is still registered to be dropped, and so if we
/// do nothing else, we would generate a `DROP(_X)` that occurs
/// after the call. This will later be optimized out by the
/// drop-elaboation code, but in the meantime it can lead to
/// drop-elaboration code, but in the meantime it can lead to
/// spurious borrow-check errors -- the problem, ironically, is
/// not the `DROP(_X)` itself, but the (spurious) unwind pathways
/// that it creates. See #64391 for an example.

4
compiler/rustc_mir_build/src/thir/pattern/deconstruct_pat.rs
View file

@ -1007,7 +1007,7 @@ impl<'tcx> SplitWildcard<'tcx> {
{
// `usize`/`isize` are not allowed to be matched exhaustively unless the
// `precise_pointer_size_matching` feature is enabled. So we treat those types like
// `#[non_exhaustive]` enums by returning a special unmatcheable constructor.
// `#[non_exhaustive]` enums by returning a special unmatchable constructor.
smallvec![NonExhaustive]
}
&ty::Int(ity) => {
@ -1650,7 +1650,7 @@ impl<'p, 'tcx> fmt::Debug for DeconstructedPat<'p, 'tcx> {
}
// Without `cx`, we can't know which field corresponds to which, so we can't
// get the names of the fields. Instead we just display everything as a suple
// get the names of the fields. Instead we just display everything as a tuple
// struct, which should be good enough.
write!(f, "(")?;
for p in self.iter_fields() {

6
compiler/rustc_mir_build/src/thir/pattern/usefulness.rs
View file

@ -62,7 +62,7 @@
//!
//! Note: we will often abbreviate "constructor" as "ctor".
//!
//! The idea that powers everything that is done in this file is the following: a (matcheable)
//! The idea that powers everything that is done in this file is the following: a (matchable)
//! value is made from a constructor applied to a number of subvalues. Examples of constructors are
//! `Some`, `None`, `(,)` (the 2-tuple constructor), `Foo {..}` (the constructor for a struct
//! `Foo`), and `2` (the constructor for the number `2`). This is natural when we think of
@ -71,7 +71,7 @@
//! Some of the ctors listed above might feel weird: `None` and `2` don't take any arguments.
//! That's ok: those are ctors that take a list of 0 arguments; they are the simplest case of
//! ctors. We treat `2` as a ctor because `u64` and other number types behave exactly like a huge
//! `enum`, with one variant for each number. This allows us to see any matcheable value as made up
//! `enum`, with one variant for each number. This allows us to see any matchable value as made up
//! from a tree of ctors, each having a set number of children. For example: `Foo { bar: None,
//! baz: Ok(0) }` is made from 4 different ctors, namely `Foo{..}`, `None`, `Ok` and `0`.
//!
@ -342,7 +342,7 @@ pub(super) struct PatCtxt<'a, 'p, 'tcx> {
/// Whether the current pattern is the whole pattern as found in a match arm, or if it's a
/// subpattern.
pub(super) is_top_level: bool,
/// Wether the current pattern is from a `non_exhaustive` enum.
/// Whether the current pattern is from a `non_exhaustive` enum.
pub(super) is_non_exhaustive: bool,
}