diff --git a/tokio/src/net/unix/pipe.rs b/tokio/src/net/unix/pipe.rs
index efe9b5ee8..27620508c 100644
--- a/tokio/src/net/unix/pipe.rs
+++ b/tokio/src/net/unix/pipe.rs
@@ -22,13 +22,12 @@ cfg_io_util! {
 /// Generally speaking, when using `OpenOptions`, you'll first call [`new`],
 /// then chain calls to methods to set each option, then call either
 /// [`open_receiver`] or [`open_sender`], passing the path of the FIFO file you
-/// are trying to open. This will give you a [`io::Result`][result] with a pipe
-/// end inside that you can further operate on.
+/// are trying to open. This will give you a [`io::Result`] with a pipe end
+/// inside that you can further operate on.
 ///
 /// [`new`]: OpenOptions::new
 /// [`open_receiver`]: OpenOptions::open_receiver
 /// [`open_sender`]: OpenOptions::open_sender
-/// [result]: std::io::Result
 ///
 /// # Examples
 ///
diff --git a/tokio/src/runtime/context.rs b/tokio/src/runtime/context.rs
index 5943e9aa9..c49c08932 100644
--- a/tokio/src/runtime/context.rs
+++ b/tokio/src/runtime/context.rs
@@ -80,23 +80,23 @@ tokio_thread_local! {
             #[cfg(feature = "rt")]
             thread_id: Cell::new(None),
 
-            /// Tracks the current runtime handle to use when spawning,
-            /// accessing drivers, etc...
+            // Tracks the current runtime handle to use when spawning,
+            // accessing drivers, etc...
             #[cfg(feature = "rt")]
             current: current::HandleCell::new(),
 
-            /// Tracks the current scheduler internal context
+            // Tracks the current scheduler internal context
             #[cfg(feature = "rt")]
             scheduler: Scoped::new(),
 
             #[cfg(feature = "rt")]
             current_task_id: Cell::new(None),
 
-            /// Tracks if the current thread is currently driving a runtime.
-            /// Note, that if this is set to "entered", the current scheduler
-            /// handle may not reference the runtime currently executing. This
-            /// is because other runtime handles may be set to current from
-            /// within a runtime.
+            // Tracks if the current thread is currently driving a runtime.
+            // Note, that if this is set to "entered", the current scheduler
+            // handle may not reference the runtime currently executing. This
+            // is because other runtime handles may be set to current from
+            // within a runtime.
             #[cfg(feature = "rt")]
             runtime: Cell::new(EnterRuntime::NotEntered),
 
diff --git a/tokio/src/sync/mod.rs b/tokio/src/sync/mod.rs
index 8af253631..33f3a35f1 100644
--- a/tokio/src/sync/mod.rs
+++ b/tokio/src/sync/mod.rs
@@ -85,7 +85,6 @@
 //! }
 //! ```
 //!
-//! [oneshot]: oneshot
 //! [`JoinHandle`]: crate::task::JoinHandle
 //!
 //! ## `mpsc` channel
@@ -175,11 +174,11 @@
 //! }
 //! ```
 //!
-//! The [`mpsc`][mpsc] and [`oneshot`][oneshot] channels can be combined to
-//! provide a request / response type synchronization pattern with a shared
-//! resource. A task is spawned to synchronize a resource and waits on commands
-//! received on a [`mpsc`][mpsc] channel. Each command includes a
-//! [`oneshot`][oneshot] `Sender` on which the result of the command is sent.
+//! The [`mpsc`] and [`oneshot`] channels can be combined to provide a request /
+//! response type synchronization pattern with a shared resource. A task is
+//! spawned to synchronize a resource and waits on commands received on a
+//! [`mpsc`] channel. Each command includes a [`oneshot`] `Sender` on which the
+//! result of the command is sent.
 //!
 //! **Example:** use a task to synchronize a `u64` counter. Each task sends an
 //! "fetch and increment" command. The counter value **before** the increment is
@@ -236,8 +235,6 @@
 //! }
 //! ```
 //!
-//! [mpsc]: mpsc
-//!
 //! ## `broadcast` channel
 //!
 //! The [`broadcast` channel] supports sending **many** values from
@@ -416,24 +413,24 @@
 //! operate in a similar way as their `std` counterparts but will wait
 //! asynchronously instead of blocking the thread.
 //!
-//! * [`Barrier`](Barrier) Ensures multiple tasks will wait for each other to
-//!   reach a point in the program, before continuing execution all together.
+//! * [`Barrier`] Ensures multiple tasks will wait for each other to reach a
+//!   point in the program, before continuing execution all together.
 //!
-//! * [`Mutex`](Mutex) Mutual Exclusion mechanism, which ensures that at most
-//!   one thread at a time is able to access some data.
+//! * [`Mutex`] Mutual Exclusion mechanism, which ensures that at most one
+//!   thread at a time is able to access some data.
 //!
-//! * [`Notify`](Notify) Basic task notification. `Notify` supports notifying a
+//! * [`Notify`] Basic task notification. `Notify` supports notifying a
 //!   receiving task without sending data. In this case, the task wakes up and
 //!   resumes processing.
 //!
-//! * [`RwLock`](RwLock) Provides a mutual exclusion mechanism which allows
-//!   multiple readers at the same time, while allowing only one writer at a
-//!   time. In some cases, this can be more efficient than a mutex.
+//! * [`RwLock`] Provides a mutual exclusion mechanism which allows multiple
+//!   readers at the same time, while allowing only one writer at a time. In
+//!   some cases, this can be more efficient than a mutex.
 //!
-//! * [`Semaphore`](Semaphore) Limits the amount of concurrency. A semaphore
-//!   holds a number of permits, which tasks may request in order to enter a
-//!   critical section. Semaphores are useful for implementing limiting or
-//!   bounding of any kind.
+//! * [`Semaphore`] Limits the amount of concurrency. A semaphore holds a
+//!   number of permits, which tasks may request in order to enter a critical
+//!   section. Semaphores are useful for implementing limiting or bounding of
+//!   any kind.
 
 cfg_sync! {
     /// Named future types.