lint: remove double spaces from docs and doc tests

.cirrus.yml

@@ -7,9 +7,9 @@ env:
   RUST_NIGHTLY: nightly-2024-05-05
   RUSTFLAGS: -D warnings
 
-# Test FreeBSD in a full VM on cirrus-ci.com.  Test the i686 target too, in the
-# same VM.  The binary will be built in 32-bit mode, but will execute on a
-# 64-bit kernel and in a 64-bit environment.  Our tests don't execute any of
+# Test FreeBSD in a full VM on cirrus-ci.com. Test the i686 target too, in the
+# same VM. The binary will be built in 32-bit mode, but will execute on a
+# 64-bit kernel and in a 64-bit environment. Our tests don't execute any of
 # the system's binaries, so the environment shouldn't matter.
 task:
   name: FreeBSD 64-bit

CONTRIBUTING.md

@@ -560,7 +560,7 @@ _Adapted from the [Node.js contributing guide][node]_.
 
 The Tokio GitHub repository has a lot of issues and PRs to keep track of. This
 section explains the meaning of various labels, as well as our [GitHub
-project][project]. The section is primarily targeted at maintainers.  Most
+project][project]. The section is primarily targeted at maintainers. Most
 contributors aren't able to set these labels.
 
 ### Area

README.md

@@ -196,7 +196,7 @@ release. The MSRV history for past minor releases can be found below:
  * 1.27 to 1.29 - Rust 1.56
  * 1.17 to 1.26 - Rust 1.49
  * 1.15 to 1.16 - Rust 1.46
- * 1.0 to 1.14 - Rust 1.45
+ * 1.0 to 1.14  - Rust 1.45
 
 Note that although we try to avoid the situation where a dependency transitively
 increases the MSRV of Tokio, we do not guarantee that this does not happen.

tokio-util/src/codec/length_delimited.rs

@@ -271,7 +271,7 @@
 //! second half of the head is needed.
 //!
 //! `length_field_offset` indicates how many bytes to skip before starting
-//! to read the length field.  `length_adjustment` is the number of bytes to
+//! to read the length field. `length_adjustment` is the number of bytes to
 //! skip starting at the end of the length field. In this case, it is the
 //! second half of the head.
 //!

tokio-util/src/codec/mod.rs

@@ -77,7 +77,7 @@
 //! A [`Decoder`] is used together with [`FramedRead`] or [`Framed`] to turn an
 //! [`AsyncRead`] into a [`Stream`]. The job of the decoder trait is to specify
 //! how sequences of bytes are turned into a sequence of frames, and to
-//! determine where the boundaries between frames are.  The job of the
+//! determine where the boundaries between frames are. The job of the
 //! `FramedRead` is to repeatedly switch between reading more data from the IO
 //! resource, and asking the decoder whether we have received enough data to
 //! decode another frame of data.
@@ -108,7 +108,7 @@
 //! It is guaranteed that, from one call to `decode` to another, the provided
 //! buffer will contain the exact same data as before, except that if more data
 //! has arrived through the IO resource, that data will have been appended to
-//! the buffer.  This means that reading frames from a `FramedRead` is
+//! the buffer. This means that reading frames from a `FramedRead` is
 //! essentially equivalent to the following loop:
 //!
 //! ```no_run
@@ -217,7 +217,7 @@
 //!
 //! An [`Encoder`] is used together with [`FramedWrite`] or [`Framed`] to turn
 //! an [`AsyncWrite`] into a [`Sink`]. The job of the encoder trait is to
-//! specify how frames are turned into a sequences of bytes.  The job of the
+//! specify how frames are turned into a sequences of bytes. The job of the
 //! `FramedWrite` is to take the resulting sequence of bytes and write it to the
 //! IO resource.
 //!

tokio-util/src/io/sync_bridge.rs

@@ -122,9 +122,9 @@ impl<T: Unpin> SyncIoBridge<T> {
     /// by e.g. [`tokio::task::spawn_blocking`].
     ///
     /// Stated even more strongly: to make use of this bridge, you *must* move
-    /// it into a separate thread outside the runtime.  The synchronous I/O will use the
+    /// it into a separate thread outside the runtime. The synchronous I/O will use the
     /// underlying handle to block on the backing asynchronous source, via
-    /// [`tokio::runtime::Handle::block_on`].  As noted in the documentation for that
+    /// [`tokio::runtime::Handle::block_on`]. As noted in the documentation for that
     /// function, an attempt to `block_on` from an asynchronous execution context
     /// will panic.
     ///

tokio-util/src/sync/mpsc.rs

@@ -15,7 +15,7 @@ impl<T> PollSendError<T> {
     /// Consumes the stored value, if any.
     ///
     /// If this error was encountered when calling `start_send`/`send_item`, this will be the item
-    /// that the caller attempted to send.  Otherwise, it will be `None`.
+    /// that the caller attempted to send. Otherwise, it will be `None`.
     pub fn into_inner(self) -> Option<T> {
         self.0
     }
@@ -47,7 +47,7 @@ pub struct PollSender<T> {
     acquire: PollSenderFuture<T>,
 }
 
-// Creates a future for acquiring a permit from the underlying channel.  This is used to ensure
+// Creates a future for acquiring a permit from the underlying channel. This is used to ensure
 // there's capacity for a send to complete.
 //
 // By reusing the same async fn for both `Some` and `None`, we make sure every future passed to
@@ -133,7 +133,7 @@ impl<T: Send> PollSender<T> {
     ///
     /// # Errors
     ///
-    /// If the channel is closed, an error will be returned.  This is a permanent state.
+    /// If the channel is closed, an error will be returned. This is a permanent state.
     pub fn poll_reserve(&mut self, cx: &mut Context<'_>) -> Poll<Result<(), PollSendError<T>>> {
         loop {
             let (result, next_state) = match self.take_state() {
@@ -173,7 +173,7 @@ impl<T: Send> PollSender<T> {
     ///
     /// # Errors
     ///
-    /// If the channel is closed, an error will be returned.  This is a permanent state.
+    /// If the channel is closed, an error will be returned. This is a permanent state.
     ///
     /// # Panics
     ///
@@ -221,8 +221,8 @@ impl<T: Send> PollSender<T> {
     /// remain open until all senders have dropped, or until the [`Receiver`] closes the channel.
     ///
     /// If a slot was previously reserved by calling `poll_reserve`, then a final call can be made
-    /// to `send_item` in order to consume the reserved slot.  After that, no further sends will be
-    /// possible.  If you do not intend to send another item, you can release the reserved slot back
+    /// to `send_item` in order to consume the reserved slot. After that, no further sends will be
+    /// possible. If you do not intend to send another item, you can release the reserved slot back
     /// to the underlying sender by calling [`abort_send`].
     ///
     /// [`abort_send`]: crate::sync::PollSender::abort_send
@@ -232,7 +232,7 @@ impl<T: Send> PollSender<T> {
         self.sender = None;
 
         // If we're already idle, closed, or we haven't yet reserved a slot, we can quickly
-        // transition to the closed state.  Otherwise, leave the existing permit in place for the
+        // transition to the closed state. Otherwise, leave the existing permit in place for the
         // caller if they want to complete the send.
         match self.state {
             State::Idle(_) => self.state = State::Closed,
@@ -246,12 +246,12 @@ impl<T: Send> PollSender<T> {
 
     /// Aborts the current in-progress send, if any.
     ///
-    /// Returns `true` if a send was aborted.  If the sender was closed prior to calling
+    /// Returns `true` if a send was aborted. If the sender was closed prior to calling
     /// `abort_send`, then the sender will remain in the closed state, otherwise the sender will be
     /// ready to attempt another send.
     pub fn abort_send(&mut self) -> bool {
         // We may have been closed in the meantime, after a call to `poll_reserve` already
-        // succeeded.  We'll check if `self.sender` is `None` to see if we should transition to the
+        // succeeded. We'll check if `self.sender` is `None` to see if we should transition to the
         // closed state when we actually abort a send, rather than resetting ourselves back to idle.
 
         let (result, next_state) = match self.take_state() {
@@ -268,7 +268,7 @@ impl<T: Send> PollSender<T> {
                 };
                 (true, state)
             }
-            // We got the permit.  If we haven't closed yet, get the sender back.
+            // We got the permit. If we haven't closed yet, get the sender back.
             State::ReadyToSend(permit) => {
                 let state = if self.sender.is_some() {
                     State::Idle(permit.release())

tokio-util/src/task/join_map.rs

@@ -13,7 +13,7 @@ use tokio::task::{AbortHandle, Id, JoinError, JoinSet, LocalSet};
 /// keys.
 ///
 /// This type is very similar to the [`JoinSet`] type in `tokio::task`, with the
-/// addition of a  set of keys associated with each task. These keys allow
+/// addition of a set of keys associated with each task. These keys allow
 /// [cancelling a task][abort] or [multiple tasks][abort_matching] in the
 /// `JoinMap` based on   their keys, or [test whether a task corresponding to a
 /// given key exists][contains] in the `JoinMap`.
@@ -463,7 +463,7 @@ where
     ///    completed. The `value` is the return value of that ask, and `key` is
     ///    the key associated with the task.
     ///  * `Some((key, Err(err))` if one of the tasks in this `JoinMap` has
-    ///    panicked or been aborted. `key` is the key associated  with the task
+    ///    panicked or been aborted. `key` is the key associated with the task
     ///    that panicked or was aborted.
     ///  * `None` if the `JoinMap` is empty.
     ///

tokio-util/src/time/wheel/mod.rs

@@ -164,7 +164,7 @@ where
             } else {
                 // in this case the poll did not indicate an expiration
                 // _and_ we were not able to find a next expiration in
-                // the current list of timers.  advance to the poll's
+                // the current list of timers. Advance to the poll's
                 // current time and do nothing else.
                 self.set_elapsed(now);
                 return None;
@@ -203,8 +203,8 @@ where
         res
     }
 
-    /// iteratively find entries that are between the wheel's current
-    /// time and the expiration time.  for each in that population either
+    /// Iteratively find entries that are between the wheel's current
+    /// time and the expiration time. For each in that population either
     /// return it for notification (in the case of the last level) or tier
     /// it down to the next level (in all other cases).
     pub(crate) fn poll_expiration(

tokio-util/tests/time_delay_queue.rs

@@ -539,8 +539,8 @@ async fn reset_later_after_slot_starts() {
 
     // At this point the queue hasn't been polled, so `elapsed` on the wheel
     // for the queue is still at 0 and hence the 1ms resolution slots cover
-    // [0-64).  Resetting the time on the entry to 120 causes it to get put in
-    // the [64-128) slot.  As the queue knows that the first entry is within
+    // [0-64). Resetting the time on the entry to 120 causes it to get put in
+    // the [64-128) slot. As the queue knows that the first entry is within
     // that slot, but doesn't know when, it must wake immediately to advance
     // the wheel.
     queue.reset_at(&foo, now + ms(120));
@@ -601,8 +601,8 @@ async fn reset_earlier_after_slot_starts() {
 
     // At this point the queue hasn't been polled, so `elapsed` on the wheel
     // for the queue is still at 0 and hence the 1ms resolution slots cover
-    // [0-64).  Resetting the time on the entry to 120 causes it to get put in
-    // the [64-128) slot.  As the queue knows that the first entry is within
+    // [0-64). Resetting the time on the entry to 120 causes it to get put in
+    // the [64-128) slot. As the queue knows that the first entry is within
     // that slot, but doesn't know when, it must wake immediately to advance
     // the wheel.
     queue.reset_at(&foo, now + ms(120));

tokio/README.md

@@ -196,7 +196,7 @@ release. The MSRV history for past minor releases can be found below:
  * 1.27 to 1.29 - Rust 1.56
  * 1.17 to 1.26 - Rust 1.49
  * 1.15 to 1.16 - Rust 1.46
- * 1.0 to 1.14 - Rust 1.45
+ * 1.0 to 1.14  - Rust 1.45
 
 Note that although we try to avoid the situation where a dependency transitively
 increases the MSRV of Tokio, we do not guarantee that this does not happen.

tokio/src/fs/metadata.rs

@@ -15,7 +15,7 @@ use std::path::Path;
 /// # Platform-specific behavior
 ///
 /// This function currently corresponds to the `stat` function on Unix and the
-/// `GetFileAttributesEx` function on Windows.  Note that, this [may change in
+/// `GetFileAttributesEx` function on Windows. Note that, this [may change in
 /// the future][changes].
 ///
 /// [changes]: https://doc.rust-lang.org/std/io/index.html#platform-specific-behavior

tokio/src/fs/mocks.rs

@@ -20,7 +20,7 @@ mock! {
         pub fn create(pb: PathBuf) -> io::Result<Self>;
         // These inner_ methods exist because std::fs::File has two
         // implementations for each of these methods: one on "&mut self" and
-        // one on "&&self".  Defining both of those in terms of an inner_ method
+        // one on "&&self". Defining both of those in terms of an inner_ method
         // allows us to specify the expectation the same way, regardless of
         // which method is used.
         pub fn inner_flush(&self) -> io::Result<()>;

tokio/src/fs/open_options.rs

@@ -165,7 +165,7 @@ impl OpenOptions {
     /// Sets the option for the append mode.
     ///
     /// This option, when true, means that writes will append to a file instead
-    /// of overwriting previous contents.  Note that setting
+    /// of overwriting previous contents. Note that setting
     /// `.write(true).append(true)` has the same effect as setting only
     /// `.append(true)`.
     ///
@@ -292,7 +292,7 @@ impl OpenOptions {
 
     /// Sets the option to always create a new file.
     ///
-    /// This option indicates whether a new file will be created.  No file is
+    /// This option indicates whether a new file will be created. No file is
     /// allowed to exist at the target location, also no (dangling) symlink.
     ///
     /// This option is useful because it is atomic. Otherwise between checking

tokio/src/io/async_fd.rs

@@ -67,7 +67,7 @@ use std::{task::Context, task::Poll};
 /// # Examples
 ///
 /// This example shows how to turn [`std::net::TcpStream`] asynchronous using
-/// `AsyncFd`.  It implements the read/write operations both as an `async fn`
+/// `AsyncFd`. It implements the read/write operations both as an `async fn`
 /// and using the IO traits [`AsyncRead`] and [`AsyncWrite`].
 ///
 /// ```no_run

tokio/src/io/async_write.rs

@@ -28,7 +28,7 @@ use std::task::{Context, Poll};
 /// This trait importantly means that the [`write`][stdwrite] method only works in
 /// the context of a future's task. The object may panic if used outside of a task.
 ///
-/// Note that this trait also represents that the  [`Write::flush`][stdflush] method
+/// Note that this trait also represents that the [`Write::flush`][stdflush] method
 /// works very similarly to the `write` method, notably that `Ok(())` means that the
 /// writer has successfully been flushed, a "would block" error means that the
 /// current task is ready to receive a notification when flushing can make more

tokio/src/io/bsd/poll_aio.rs

@@ -70,7 +70,7 @@ impl<T: AioSource> Source for MioSource<T> {
 ///
 /// If [`Aio::poll_ready`] returns ready, but the consumer determines that the
 /// Source is not completely ready and must return to the Pending state,
-/// [`Aio::clear_ready`] may be used.  This can be useful with
+/// [`Aio::clear_ready`] may be used. This can be useful with
 /// [`lio_listio`], which may generate a kevent when only a portion of the
 /// operations have completed.
 ///
@@ -82,10 +82,10 @@ impl<T: AioSource> Source for MioSource<T> {
 /// [`lio_listio`]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/lio_listio.html
 // Note: Unlike every other kqueue event source, POSIX AIO registers events not
 // via kevent(2) but when the aiocb is submitted to the kernel via aio_read,
-// aio_write, etc.  It needs the kqueue's file descriptor to do that.  So
+// aio_write, etc. It needs the kqueue's file descriptor to do that. So
 // AsyncFd can't be used for POSIX AIO.
 //
-// Note that Aio doesn't implement Drop.  There's no need.  Unlike other
+// Note that Aio doesn't implement Drop. There's no need. Unlike other
 // kqueue sources, simply dropping the object effectively deregisters it.
 pub struct Aio<E> {
     io: MioSource<E>,
@@ -97,7 +97,7 @@ pub struct Aio<E> {
 impl<E: AioSource> Aio<E> {
     /// Creates a new `Aio` suitable for use with POSIX AIO functions.
     ///
-    /// It will be associated with the default reactor.  The runtime is usually
+    /// It will be associated with the default reactor. The runtime is usually
     /// set implicitly when this function is called from a future driven by a
     /// Tokio runtime, otherwise runtime can be set explicitly with
     /// [`Runtime::enter`](crate::runtime::Runtime::enter) function.
@@ -107,7 +107,7 @@ impl<E: AioSource> Aio<E> {
 
     /// Creates a new `Aio` suitable for use with [`lio_listio`].
     ///
-    /// It will be associated with the default reactor.  The runtime is usually
+    /// It will be associated with the default reactor. The runtime is usually
     /// set implicitly when this function is called from a future driven by a
     /// Tokio runtime, otherwise runtime can be set explicitly with
     /// [`Runtime::enter`](crate::runtime::Runtime::enter) function.
@@ -124,20 +124,20 @@ impl<E: AioSource> Aio<E> {
         Ok(Self { io, registration })
     }
 
-    /// Indicates to Tokio that the source is no longer ready.  The internal
+    /// Indicates to Tokio that the source is no longer ready. The internal
     /// readiness flag will be cleared, and tokio will wait for the next
     /// edge-triggered readiness notification from the OS.
     ///
     /// It is critical that this method not be called unless your code
-    /// _actually observes_ that the source is _not_ ready.  The OS must
+    /// _actually observes_ that the source is _not_ ready. The OS must
     /// deliver a subsequent notification, or this source will block
-    /// forever.  It is equally critical that you `do` call this method if you
+    /// forever. It is equally critical that you `do` call this method if you
     /// resubmit the same structure to the kernel and poll it again.
     ///
     /// This method is not very useful with AIO readiness, since each `aiocb`
-    /// structure is typically only used once.  It's main use with
+    /// structure is typically only used once. It's main use with
     /// [`lio_listio`], which will sometimes send notification when only a
-    /// portion of its elements are complete.  In that case, the caller must
+    /// portion of its elements are complete. In that case, the caller must
     /// call `clear_ready` before resubmitting it.
     ///
     /// [`lio_listio`]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/lio_listio.html
@@ -150,14 +150,14 @@ impl<E: AioSource> Aio<E> {
         self.io.0
     }
 
-    /// Polls for readiness.  Either AIO or LIO counts.
+    /// Polls for readiness. Either AIO or LIO counts.
     ///
     /// This method returns:
     ///  * `Poll::Pending` if the underlying operation is not complete, whether
-    ///     or not it completed successfully.  This will be true if the OS is
+    ///     or not it completed successfully. This will be true if the OS is
     ///     still processing it, or if it has not yet been submitted to the OS.
     ///  * `Poll::Ready(Ok(_))` if the underlying operation is complete.
-    ///  * `Poll::Ready(Err(_))` if the reactor has been shutdown.  This does
+    ///  * `Poll::Ready(Err(_))` if the reactor has been shutdown. This does
     ///     _not_ indicate that the underlying operation encountered an error.
     ///
     /// When the method returns `Poll::Pending`, the `Waker` in the provided `Context`

tokio/src/io/mod.rs

@@ -154,7 +154,7 @@
 //! 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.
 //!