Backticked more words & trim down dictionary

Backticked more words & trim down dictionary

spellcheck.dic

@@ -1,4 +1,4 @@
-286
+265
 \
 ~
 ~4
@@ -32,9 +32,6 @@ Adaptors
 AIO
 ambiant
 amongst
-api
-APIs
-assert_eq
 async
 awaitable
 backend
@@ -43,28 +40,18 @@ backtrace
 backtraces
 backtracing
 binded
-bitfield
-bitfields
 Blockingly
-bool
-boolean
 broadcasted
-buf
 cancelled
 cancelling
 Cancelling
-cfg
 CLI
 cloneable
 codebase
 codec
 codecs
 combinator
 combinators
-Config
-config
-connectionless
-const
 cpu
 cpus
 Customizable
@@ -110,10 +97,7 @@ filesystems
 fn
 fns
 FreeBSD
-frontend
-fs
 functionalities
-fuzz_linked_list
 getters
 GID
 Growable
@@ -167,7 +151,6 @@ Nagle
 nonblocking
 nondecreasing
 noop
-notitifications
 ntasks
 ok
 oneshot
@@ -204,10 +187,6 @@ runtime's
 rwlock
 rx
 scalability
-scheduler's
-semver
-setpgid
-shard_id
 sharded
 signalled
 signalling

tokio-macros/src/entry.rs

@@ -32,7 +32,7 @@ struct FinalConfig {
     crate_name: Option<Path>,
 }
 
-/// Config used in case of the attribute not being able to build a valid config
+/// `Config` used in case of the attribute not being able to build a valid `config`
 const DEFAULT_ERROR_CONFIG: FinalConfig = FinalConfig {
     flavor: RuntimeFlavor::CurrentThread,
     worker_threads: None,

tokio-util/src/io/mod.rs

@@ -4,7 +4,7 @@
 //! allow converting between a hyper [`Body`] and [`AsyncRead`].
 //!
 //! The [`SyncIoBridge`] type converts from the world of async I/O
-//! to synchronous I/O; this may often come up when using synchronous APIs
+//! to synchronous I/O; this may often come up when using synchronous `APIs`
 //! inside [`tokio::task::spawn_blocking`].
 //!
 //! [`Body`]: https://docs.rs/hyper/0.13/hyper/struct.Body.html

tokio-util/src/task/task_tracker.rs

@@ -23,7 +23,7 @@ use tokio::{
 /// `CancellationToken` is used to signal to tasks that they should shut down, and the
 /// `TaskTracker` is used to wait for them to finish shutting down.
 ///
-/// The `TaskTracker` will also keep track of a `closed` boolean. This is used to handle the case
+/// The `TaskTracker` will also keep track of a `closed` `boolean`. This is used to handle the case
 /// where the `TaskTracker` is empty, but we don't want to shut down yet. This means that the
 /// [`wait`] method will wait until *both* of the following happen at the same time:
 ///

tokio/src/fs/mocks.rs

@@ -1,4 +1,4 @@
-//! Mock version of std::fs::File;
+//! Mock version of `std::fs::File`;
 use mockall::mock;
 
 use crate::sync::oneshot;

tokio/src/io/async_fd.rs

@@ -55,7 +55,7 @@ use std::{task::Context, task::Poll};
 ///
 /// ## Use with to a poll-based API
 ///
-/// In some cases it may be desirable to use `AsyncFd` from APIs similar to
+/// In some cases it may be desirable to use `AsyncFd` from `APIs` similar to
 /// [`TcpStream::poll_read_ready`]. The [`AsyncFd::poll_read_ready`] and
 /// [`AsyncFd::poll_write_ready`] functions are provided for this purpose.
 /// Because these functions don't create a future to hold their state, they have

tokio/src/io/mod.rs

@@ -150,11 +150,11 @@
 //!
 //! # Standard input and output
 //!
-//! Tokio provides asynchronous APIs to standard [input], [output], and [error].
-//! These APIs are very similar to the ones provided by `std`, but they also
+//! Tokio provides asynchronous `APIs` to standard [input], [output], and [error].
+//! These `APIs` are very similar to the ones provided by `std`, but they also
 //! implement [`AsyncRead`] and [`AsyncWrite`].
 //!
-//! Note that the standard input / output APIs  **must** be used from the
+//! Note that the standard input / output `APIs`  **must** be used from the
 //! context of the Tokio runtime, as they require Tokio-specific features to
 //! function. Calling these functions outside of a Tokio runtime will panic.
 //!

tokio/src/io/util/read_line.rs

@@ -51,7 +51,7 @@ fn put_back_original_data(output: &mut String, mut vector: Vec<u8>, num_bytes_re
 
 /// This handles the various failure cases and puts the string back into `output`.
 ///
-/// The `truncate_on_io_error` bool is necessary because `read_to_string` and `read_line`
+/// The `truncate_on_io_error` `bool` is necessary because `read_to_string` and `read_line`
 /// disagree on what should happen when an IO error occurs.
 pub(super) fn finish_string_read(
     io_res: io::Result<usize>,

tokio/src/lib.rs

@@ -28,7 +28,7 @@
 //! * Tools for [working with asynchronous tasks][tasks], including
 //!   [synchronization primitives and channels][sync] and [timeouts, sleeps, and
 //!   intervals][time].
-//! * APIs for [performing asynchronous I/O][io], including [TCP and UDP][net] sockets,
+//! * `APIs` for [performing asynchronous I/O][io], including [TCP and UDP][net] sockets,
 //!   [filesystem][fs] operations, and [process] and [signal] management.
 //! * A [runtime] for executing asynchronous code, including a task scheduler,
 //!   an I/O driver backed by the operating system's event queue (`epoll`, `kqueue`,
@@ -52,7 +52,7 @@
 //!
 //! Tokio consists of a number of modules that provide a range of functionality
 //! essential for implementing asynchronous applications in Rust. In this
-//! section, we will take a brief tour of Tokio, summarizing the major APIs and
+//! section, we will take a brief tour of Tokio, summarizing the major `APIs` and
 //! their uses.
 //!
 //! The easiest way to get started is to enable all features. Do this by
@@ -149,7 +149,7 @@
 //! Finally, Tokio provides a _runtime_ for executing asynchronous tasks. Most
 //! applications can use the [`#[tokio::main]`][main] macro to run their code on the
 //! Tokio runtime. However, this macro provides only basic configuration options. As
-//! an alternative, the [`tokio::runtime`] module provides more powerful APIs for configuring
+//! an alternative, the [`tokio::runtime`] module provides more powerful `APIs` for configuring
 //! and managing runtimes. You should use that module if the `#[tokio::main]` macro doesn't
 //! provide the functionality you need.
 //!
@@ -234,13 +234,13 @@
 //! functions for working with these traits, forming as an asynchronous
 //! counterpart to [`std::io`].
 //!
-//! Tokio also includes APIs for performing various kinds of I/O and interacting
+//! Tokio also includes `APIs` for performing various kinds of I/O and interacting
 //! with the operating system asynchronously. These include:
 //!
 //! * [`tokio::net`], which contains non-blocking versions of [TCP], [UDP], and
 //!   [Unix Domain Sockets][UDS] (enabled by the "net" feature flag),
 //! * [`tokio::fs`], similar to [`std::fs`] but for performing filesystem I/O
-//!   asynchronously (enabled by the "fs" feature flag),
+//!   asynchronously (enabled by the `"fs"` feature flag),
 //! * [`tokio::signal`], for asynchronously handling Unix and Windows OS signals
 //!   (enabled by the "signal" feature flag),
 //! * [`tokio::process`], for spawning and managing child processes (enabled by
@@ -309,7 +309,7 @@
 //! case. Below is a list of the available feature flags. You may also notice
 //! above each function, struct and trait there is listed one or more feature flags
 //! that are required for that item to be used. If you are new to Tokio it is
-//! recommended that you use the `full` feature flag which will enable all public APIs.
+//! recommended that you use the `full` feature flag which will enable all public `APIs`.
 //! Beware though that this will pull in many extra dependencies that you may not
 //! need.
 //!
@@ -333,7 +333,7 @@
 //! - `parking_lot`: As a potential optimization, use the `_parking_lot_` crate's
 //!                  synchronization primitives internally. Also, this
 //!                  dependency is necessary to construct some of our primitives
-//!                  in a const context. `MSRV` may increase according to the
+//!                  in a `const` context. `MSRV` may increase according to the
 //!                  `_parking_lot_` release in use.
 //!
 //! _Note: `AsyncRead` and `AsyncWrite` traits do not require any features and are
@@ -356,7 +356,7 @@
 //! This flag enables **unstable** features. The public API of these features
 //! may break in 1.x releases. To enable these features, the `--cfg
 //! tokio_unstable` argument must be passed to `rustc` when compiling. This
-//! serves to explicitly opt-in to features which may break semver conventions,
+//! serves to explicitly opt-in to features which may break `semver` conventions,
 //! since Cargo [does not yet directly support such opt-ins][unstable features].
 //!
 //! You can specify it in your project's `.cargo/config.toml` file:
@@ -689,6 +689,6 @@ cfg_macros! {
 #[cfg(test)]
 fn is_unpin<T: Unpin>() {}
 
-/// fuzz test (fuzz_linked_list)
+/// fuzz test (`fuzz_linked_list`)
 #[cfg(fuzzing)]
 pub mod fuzz;

tokio/src/loom/std/mutex.rs

@@ -1,7 +1,7 @@
 use std::sync::{self, MutexGuard, TryLockError};
 
 /// Adapter for `std::Mutex` that removes the poisoning aspects
-/// from its api.
+/// from its `api`.
 #[derive(Debug)]
 pub(crate) struct Mutex<T: ?Sized>(sync::Mutex<T>);
 

tokio/src/net/udp.rs

@@ -13,7 +13,7 @@ cfg_io_util! {
 cfg_net! {
     /// A UDP socket.
     ///
-    /// UDP is "connectionless", unlike TCP. Meaning, regardless of what address you've bound to, a `UdpSocket`
+    /// UDP is `"connectionless"`, unlike TCP. Meaning, regardless of what address you've bound to, a `UdpSocket`
     /// is free to communicate with many different remotes. In tokio there are basically two main ways to use `UdpSocket`:
     ///
     /// * one to many: [`bind`](`UdpSocket::bind`) and use [`send_to`](`UdpSocket::send_to`)
@@ -825,7 +825,7 @@ impl UdpSocket {
     /// address to which it is connected. On success, returns the number of
     /// bytes read.
     ///
-    /// This method must be called with valid byte array buf of sufficient size
+    /// This method must be called with valid byte array `buf` of sufficient size
     /// to hold the message bytes. If a message is too long to fit in the
     /// supplied buffer, excess bytes may be discarded.
     ///
@@ -881,7 +881,7 @@ impl UdpSocket {
         /// Tries to receive data from the stream into the provided buffer, advancing the
         /// buffer's internal cursor, returning how many bytes were read.
         ///
-        /// This method must be called with valid byte array buf of sufficient size
+        /// This method must be called with valid byte array `buf` of sufficient size
         /// to hold the message bytes. If a message is too long to fit in the
         /// supplied buffer, excess bytes may be discarded.
         ///
@@ -949,7 +949,7 @@ impl UdpSocket {
         /// to which it is connected, advancing the buffer's internal cursor,
         /// returning how many bytes were read.
         ///
-        /// This method must be called with valid byte array buf of sufficient size
+        /// This method must be called with valid byte array `buf` of sufficient size
         /// to hold the message bytes. If a message is too long to fit in the
         /// supplied buffer, excess bytes may be discarded.
         ///
@@ -996,7 +996,7 @@ impl UdpSocket {
         /// Tries to receive a single datagram message on the socket. On success,
         /// returns the number of bytes read and the origin.
         ///
-        /// This method must be called with valid byte array buf of sufficient size
+        /// This method must be called with valid byte array `buf` of sufficient size
         /// to hold the message bytes. If a message is too long to fit in the
         /// supplied buffer, excess bytes may be discarded.
         ///
@@ -1071,7 +1071,7 @@ impl UdpSocket {
         /// Receives a single datagram message on the socket, advancing the
         /// buffer's internal cursor, returning how many bytes were read and the origin.
         ///
-        /// This method must be called with valid byte array buf of sufficient size
+        /// This method must be called with valid byte array `buf` of sufficient size
         /// to hold the message bytes. If a message is too long to fit in the
         /// supplied buffer, excess bytes may be discarded.
         ///
@@ -1360,7 +1360,7 @@ impl UdpSocket {
     /// Tries to receive a single datagram message on the socket. On success,
     /// returns the number of bytes read and the origin.
     ///
-    /// This method must be called with valid byte array buf of sufficient size
+    /// This method must be called with valid byte array `buf` of sufficient size
     /// to hold the message bytes. If a message is too long to fit in the
     /// supplied buffer, excess bytes may be discarded.
     ///

tokio/src/process/mod.rs

@@ -4,7 +4,7 @@
 //! [`std::process::Command`] type in the standard library, but provides asynchronous versions of
 //! functions that create processes. These functions (`spawn`, `status`, `output` and their
 //! variants) return "future aware" types that interoperate with Tokio. The asynchronous process
-//! support is provided through signal handling on Unix and system APIs on Windows.
+//! support is provided through signal handling on Unix and system `APIs` on Windows.
 //!
 //! [`std::process::Command`]: std::process::Command
 //!

tokio/src/runtime/blocking/mod.rs

@@ -1,5 +1,5 @@
-//! Abstracts out the APIs necessary to `Runtime` for integrating the blocking
-//! pool. When the `blocking` feature flag is **not** enabled, these APIs are
+//! Abstracts out the `APIs` necessary to `Runtime` for integrating the blocking
+//! pool. When the `blocking` feature flag is **not** enabled, these `APIs` are
 //! shells. This isolates the complexity of dealing with conditional
 //! compilation.
 

tokio/src/runtime/context.rs

@@ -42,7 +42,7 @@ struct Context {
     #[cfg(feature = "rt")]
     current: current::HandleCell,
 
-    /// Handle to the scheduler's internal "context"
+    /// Handle to the `scheduler's` internal "context"
     #[cfg(feature = "rt")]
     scheduler: Scoped<scheduler::Context>,
 

tokio/src/runtime/handle.rs

@@ -475,7 +475,7 @@ cfg_taskdump! {
         /// ## Unstable Features
         ///
         /// This functionality is **unstable**, and requires both the
-        /// `tokio_unstable` and `tokio_taskdump` cfg flags to be set.
+        /// `tokio_unstable` and `tokio_taskdump` `cfg` flags to be set.
         ///
         /// You can do this by setting the `RUSTFLAGS` environment variable
         /// before invoking `cargo`; e.g.:

tokio/src/runtime/scheduler/multi_thread/worker.rs

@@ -88,7 +88,7 @@ cfg_not_taskdump! {
 
 /// A scheduler worker
 pub(super) struct Worker {
-    /// Reference to scheduler's handle
+    /// Reference to `scheduler's` handle
     handle: Arc<Handle>,
 
     /// Index holding this worker's remote state
@@ -184,7 +184,7 @@ pub(crate) struct Shared {
     /// Only held to trigger some code on drop. This is used to get internal
     /// runtime metrics that can be useful when doing performance
     /// investigations. This does nothing (empty struct, no drop impl) unless
-    /// the `tokio_internal_mt_counters` cfg flag is set.
+    /// the `tokio_internal_mt_counters` `cfg` flag is set.
     _counters: Counters,
 }
 
@@ -995,7 +995,7 @@ impl Core {
 }
 
 impl Worker {
-    /// Returns a reference to the scheduler's injection queue.
+    /// Returns a reference to the `scheduler's` injection queue.
     fn inject(&self) -> &inject::Shared<Arc<Handle>> {
         &self.handle.shared.inject
     }

tokio/src/runtime/scheduler/multi_thread_alt/worker.rs

@@ -174,7 +174,7 @@ pub(crate) struct Shared {
     /// Only held to trigger some code on drop. This is used to get internal
     /// runtime metrics that can be useful when doing performance
     /// investigations. This does nothing (empty struct, no drop impl) unless
-    /// the `tokio_internal_mt_counters` cfg flag is set.
+    /// the `tokio_internal_mt_counters` `cfg` flag is set.
     _counters: Counters,
 }
 

tokio/src/runtime/task/core.rs

@@ -28,7 +28,7 @@ use std::task::{Context, Poll, Waker};
 /// be referenced by both *mut Cell and *mut Header.
 ///
 /// Any changes to the layout of this struct _must_ also be reflected in the
-/// const fns in raw.rs.
+/// `const` fns in raw.rs.
 ///
 // # This struct should be cache padded to avoid false sharing. The cache padding rules are copied
 // from crossbeam-utils/src/cache_padded.rs
@@ -132,7 +132,7 @@ pub(super) struct CoreStage<T: Future> {
 /// Holds the future or output, depending on the stage of execution.
 ///
 /// Any changes to the layout of this struct _must_ also be reflected in the
-/// const fns in raw.rs.
+/// `const` fns in raw.rs.
 #[repr(C)]
 pub(super) struct Core<T: Future, S> {
     /// Scheduler used to drive this future.