Auto merge of #94571 - matthiaskrgr:rollup-4ul5ydb, r=matthiaskrgr

Rollup of 8 pull requests

Successful merges:

 - #92697 (Use cgroup quotas for calculating `available_parallelism`)
 - #94057 (improve comments for `simplify_type`)
 - #94547 (`parse_tt` cleanups)
 - #94550 (rustdoc: Add test for higher kinded functions generated by macros)
 - #94551 (Doc: Fix use of quote instead of backstick in Adapter::map.)
 - #94554 (Fix invalid lint_node_id being put on a removed stmt)
 - #94555 (all: fix some typos)
 - #94563 (Remove a unnecessary `..` pattern)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

RELEASES.md

@@ -1060,7 +1060,7 @@ Version 1.52.1 (2021-05-10)
 This release disables incremental compilation, unless the user has explicitly
 opted in via the newly added RUSTC_FORCE_INCREMENTAL=1 environment variable.
 
-This is due to the widespread, and frequently occuring, breakage encountered by
+This is due to the widespread, and frequently occurring, breakage encountered by
 Rust users due to newly enabled incremental verification in 1.52.0. Notably,
 Rust users **should** upgrade to 1.52.0 or 1.52.1: the bugs that are detected by
 newly added incremental verification are still present in past stable versions,

compiler/rustc_codegen_gcc/src/builder.rs

@@ -1064,7 +1064,7 @@ impl<'a, 'gcc, 'tcx> BuilderMethods<'a, 'tcx> for Builder<'a, 'gcc, 'tcx> {
         let val_type = value.get_type();
         match (type_is_pointer(val_type), type_is_pointer(dest_ty)) {
             (false, true) => {
-                // NOTE: Projecting a field of a pointer type will attemp a cast from a signed char to
+                // NOTE: Projecting a field of a pointer type will attempt a cast from a signed char to
                 // a pointer, which is not supported by gccjit.
                 return self.cx.context.new_cast(None, self.inttoptr(value, val_type.make_pointer()), dest_ty);
             },

compiler/rustc_codegen_llvm/src/llvm_util.rs

@@ -369,12 +369,12 @@ pub fn target_cpu(sess: &Session) -> &str {
 /// The list of LLVM features computed from CLI flags (`-Ctarget-cpu`, `-Ctarget-feature`,
 /// `--target` and similar).
 pub(crate) fn global_llvm_features(sess: &Session, diagnostics: bool) -> Vec<String> {
-    // Features that come earlier are overriden by conflicting features later in the string.
+    // Features that come earlier are overridden by conflicting features later in the string.
     // Typically we'll want more explicit settings to override the implicit ones, so:
     //
-    // * Features from -Ctarget-cpu=*; are overriden by [^1]
-    // * Features implied by --target; are overriden by
-    // * Features from -Ctarget-feature; are overriden by
+    // * Features from -Ctarget-cpu=*; are overridden by [^1]
+    // * Features implied by --target; are overridden by
+    // * Features from -Ctarget-feature; are overridden by
     // * function specific features.
     //
     // [^1]: target-cpu=native is handled here, other target-cpu values are handled implicitly
@@ -383,7 +383,7 @@ pub(crate) fn global_llvm_features(sess: &Session, diagnostics: bool) -> Vec<Str
     // FIXME(nagisa): it isn't clear what's the best interaction between features implied by
     // `-Ctarget-cpu` and `--target` are. On one hand, you'd expect CLI arguments to always
     // override anything that's implicit, so e.g. when there's no `--target` flag, features implied
-    // the host target are overriden by `-Ctarget-cpu=*`. On the other hand, what about when both
+    // the host target are overridden by `-Ctarget-cpu=*`. On the other hand, what about when both
     // `--target` and `-Ctarget-cpu=*` are specified? Both then imply some target features and both
     // flags are specified by the user on the CLI. It isn't as clear-cut which order of precedence
     // should be taken in cases like these.

compiler/rustc_codegen_ssa/src/debuginfo/type_names.rs

@@ -1,6 +1,6 @@
 // Type Names for Debug Info.
 
-// Notes on targetting MSVC:
+// Notes on targeting MSVC:
 // In general, MSVC's debugger attempts to parse all arguments as C++ expressions,
 // even if the argument is explicitly a symbol name.
 // As such, there are many things that cause parsing issues:

compiler/rustc_const_eval/src/interpret/operand.rs

@@ -535,7 +535,7 @@ impl<'mir, 'tcx: 'mir, M: Machine<'mir, 'tcx>> InterpCx<'mir, 'tcx, M> {
                 let val =
                     self.subst_from_current_frame_and_normalize_erasing_regions(constant.literal)?;
                 // This can still fail:
-                // * During ConstProp, with `TooGeneric` or since the `requried_consts` were not all
+                // * During ConstProp, with `TooGeneric` or since the `required_consts` were not all
                 //   checked yet.
                 // * During CTFE, since promoteds in `const`/`static` initializer bodies can fail.
 

compiler/rustc_driver/src/lib.rs

@@ -1228,7 +1228,7 @@ pub fn report_ice(info: &panic::PanicInfo<'_>, bug_report_url: &str) {
 ///
 /// A custom rustc driver can skip calling this to set up a custom ICE hook.
 pub fn install_ice_hook() {
-    // If the user has not explicitly overriden "RUST_BACKTRACE", then produce
+    // If the user has not explicitly overridden "RUST_BACKTRACE", then produce
     // full backtraces. When a compiler ICE happens, we want to gather
     // as much information as possible to present in the issue opened
     // by the user. Compiler developers and other rustc users can

compiler/rustc_error_codes/src/error_codes/E0772.md

@@ -45,7 +45,7 @@ trait object's internal data to be accessed safely from any trait methods. This
 rule also goes for any lifetime any struct made into a trait object may have.
 
 In the implementation for `dyn Person`, the `'2` lifetime representing the
-internal data was ommitted, meaning that the compiler inferred the lifetime
+internal data was omitted, meaning that the compiler inferred the lifetime
 `'static`. As a result, the implementation's `is_cool` is inferred by the
 compiler to look like this:
 

compiler/rustc_expand/src/expand.rs

@@ -1841,7 +1841,7 @@ impl<'a, 'b> MutVisitor for InvocationCollector<'a, 'b> {
         self.flat_map_node(node)
     }
 
-    fn flat_map_stmt(&mut self, mut node: ast::Stmt) -> SmallVec<[ast::Stmt; 1]> {
+    fn flat_map_stmt(&mut self, node: ast::Stmt) -> SmallVec<[ast::Stmt; 1]> {
         // FIXME: invocations in semicolon-less expressions positions are expanded as expressions,
         // changing that requires some compatibility measures.
         if node.is_expr() {
@@ -1863,7 +1863,7 @@ impl<'a, 'b> MutVisitor for InvocationCollector<'a, 'b> {
                     self.cx.current_expansion.is_trailing_mac = false;
                     res
                 }
-                _ => assign_id!(self, &mut node.id, || noop_flat_map_stmt(node, self)),
+                _ => noop_flat_map_stmt(node, self),
             };
         }