diff --git a/client/network/src/block_request_handler.rs b/client/network/src/block_request_handler.rs
index 3ea7833970d9e..9d963480a7e01 100644
--- a/client/network/src/block_request_handler.rs
+++ b/client/network/src/block_request_handler.rs
@@ -15,7 +15,7 @@
// along with Substrate. If not, see .
//! Helper for handling (i.e. answering) block requests from a remote peer via the
-//! [`crate::request_responses::RequestResponsesBehaviour`].
+//! `crate::request_responses::RequestResponsesBehaviour`.
use crate::{
chain::Client,
diff --git a/client/network/src/light_client_requests/handler.rs b/client/network/src/light_client_requests/handler.rs
index a04c5e310a67e..5ecc85bdb0a0f 100644
--- a/client/network/src/light_client_requests/handler.rs
+++ b/client/network/src/light_client_requests/handler.rs
@@ -19,7 +19,7 @@
//! Helper for incoming light client requests.
//!
//! Handle (i.e. answer) incoming light client requests from a remote peer received via
-//! [`crate::request_responses::RequestResponsesBehaviour`] with
+//! `crate::request_responses::RequestResponsesBehaviour` with
//! [`LightClientRequestHandler`](handler::LightClientRequestHandler).
use crate::{
diff --git a/client/network/src/service.rs b/client/network/src/service.rs
index caf4db89f653a..4ad284a98aa63 100644
--- a/client/network/src/service.rs
+++ b/client/network/src/service.rs
@@ -710,8 +710,7 @@ impl NetworkService {
/// > preventing the message from being delivered.
///
/// The protocol must have been registered with
- /// [`NetworkConfiguration::notifications_protocols`](crate::config::NetworkConfiguration::
- /// notifications_protocols).
+ /// `crate::config::NetworkConfiguration::notifications_protocols`.
pub fn write_notification(
&self,
target: PeerId,
@@ -775,8 +774,7 @@ impl NetworkService {
/// in which case enqueued notifications will be lost.
///
/// The protocol must have been registered with
- /// [`NetworkConfiguration::notifications_protocols`](crate::config::NetworkConfiguration::
- /// notifications_protocols).
+ /// `crate::config::NetworkConfiguration::notifications_protocols`.
///
/// # Usage
///
@@ -817,8 +815,7 @@ impl NetworkService {
/// if buffer is full
///
///
- /// See also the [`gossip`](crate::gossip) module for a higher-level way to send
- /// notifications.
+ /// See also the `sc-network-gossip` crate for a higher-level way to send notifications.
pub fn notification_sender(
&self,
target: PeerId,
diff --git a/client/network/src/state_request_handler.rs b/client/network/src/state_request_handler.rs
index 0d710c13af607..89f1f2b363c4c 100644
--- a/client/network/src/state_request_handler.rs
+++ b/client/network/src/state_request_handler.rs
@@ -15,7 +15,7 @@
// along with Substrate. If not, see .
//! Helper for handling (i.e. answering) state requests from a remote peer via the
-//! [`crate::request_responses::RequestResponsesBehaviour`].
+//! `crate::request_responses::RequestResponsesBehaviour`.
use crate::{
chain::Client,
diff --git a/client/service/src/client/mod.rs b/client/service/src/client/mod.rs
index 7743f479a1713..d10b3d16b8139 100644
--- a/client/service/src/client/mod.rs
+++ b/client/service/src/client/mod.rs
@@ -37,9 +37,8 @@
//! The latter typically requires passing one of:
//!
//! - A [`LocalCallExecutor`] running the runtime locally.
-//! - A [`RemoteCallExecutor`](sc_client_api::light::RemoteCallRequest) that will ask a
-//! third-party to perform the executions.
-//! - A [`RemoteOrLocalCallExecutor`](sc_client_api::light::LocalOrRemote), combination of the two.
+//! - A `RemoteCallExecutor` that will ask a third-party to perform the executions.
+//! - A `RemoteOrLocalCallExecutor` combination of the two.
//!
//! Additionally, the fourth generic parameter of the `Client` is a marker type representing
//! the ways in which the runtime can interface with the outside. Any code that builds a `Client`
diff --git a/utils/frame/try-runtime/cli/src/lib.rs b/utils/frame/try-runtime/cli/src/lib.rs
index 4aa1c213703ed..8b8c6b2d2bb36 100644
--- a/utils/frame/try-runtime/cli/src/lib.rs
+++ b/utils/frame/try-runtime/cli/src/lib.rs
@@ -125,7 +125,7 @@
//! #### Adding pre/post hooks
//!
//! One of the gems that come only in the `try-runtime` feature flag is the `pre_upgrade` and
-//! `post_upgrade` hooks for [`OnRuntimeUpgrade`]. This trait is implemented either inside the
+//! `post_upgrade` hooks for `OnRuntimeUpgrade`. This trait is implemented either inside the
//! pallet, or manually in a runtime, to define a migration. In both cases, these functions can be
//! added, given the right flag:
//!
@@ -141,7 +141,7 @@
//!
//! These hooks allow you to execute some code, only within the `on-runtime-upgrade` command, before
//! and after the migration. If any data needs to be temporarily stored between the pre/post
-//! migration hooks, [`OnRuntimeUpgradeHelpersExt`] can help with that.
+//! migration hooks, `OnRuntimeUpgradeHelpersExt` can help with that.
//!
//! #### Logging
//!
@@ -151,7 +151,7 @@
//!
//! #### Guarding migrations
//!
-//! Always make sure that any migration code is guarded either by [`StorageVersion`], or by some
+//! Always make sure that any migration code is guarded either by `StorageVersion`, or by some
//! custom storage item, so that it is NEVER executed twice, even if the code lives in two
//! consecutive runtimes.
//!
@@ -160,7 +160,7 @@
//! Run the migrations of the local runtime on the state of polkadot, from the polkadot repo where
//! we have `--chain polkadot-dev`, on the latest finalized block's state
//!
-//! ```ignore
+//! ```sh
//! RUST_LOG=runtime=trace,try-runtime::cli=trace,executor=trace \
//! cargo run try-runtime \
//! --execution Native \
@@ -174,7 +174,7 @@
//! Same as previous one, but let's say we want to run this command from the substrate repo, where
//! we don't have a matching spec name/version.
//!
-//! ```ignore
+//! ```sh
//! RUST_LOG=runtime=trace,try-runtime::cli=trace,executor=trace \
//! cargo run try-runtime \
//! --execution Native \
@@ -188,7 +188,7 @@
//! Same as the previous one, but run it at specific block number's state. This means that this
//! block hash's state shall not yet have been pruned in `rpc.polkadot.io`.
//!
-//! ```ignore
+//! ```sh
//! RUST_LOG=runtime=trace,try-runtime::cli=trace,executor=trace \
//! cargo run try-runtime \
//! --execution Native \
@@ -206,7 +206,7 @@
//! First, let's assume you are in a branch that has the same spec name/version as the live polkadot
//! network.
//!
-//! ```ignore
+//! ```sh
//! RUST_LOG=runtime=trace,try-runtime::cli=trace,executor=trace \
//! cargo run try-runtime \
//! --execution Wasm \
@@ -222,14 +222,14 @@
//! change `--execution Wasm` to `--execution Native` to achieve this. Your logs of `executor=trace`
//! should show something among the lines of:
//!
-//! ```ignore
+//! ```text
//! Request for native execution succeeded (native: polkadot-9900 (parity-polkadot-0.tx7.au0), chain: polkadot-9900 (parity-polkadot-0.tx7.au0))
//! ```
//!
//! If you don't have matching spec versions, then are doomed to execute wasm. In this case, you can
//! manually overwrite the wasm code with your local runtime:
//!
-//! ```ignore
+//! ```sh
//! RUST_LOG=runtime=trace,try-runtime::cli=trace,executor=trace \
//! cargo run try-runtime \
//! --execution Wasm \
@@ -242,12 +242,12 @@
//! ```
//!
//! For all of these blocks, the block with hash `` is being used, and the initial state
-//! is the state of the parent hash. This is because by omitting [`ExecuteBlockCmd::block_at`], the
+//! is the state of the parent hash. This is because by omitting `ExecuteBlockCmd::block_at`, the
//! `--at` is used for both. This should be good enough for 99% of the cases. The only case where
//! you need to specify `block-at` and `block-ws-uri` is with snapshots. Let's say you have a file
//! `snap` and you know it corresponds to the state of the parent block of `X`. Then you'd do:
//!
-//! ```ignore
+//! ```sh
//! RUST_LOG=runtime=trace,try-runtime::cli=trace,executor=trace \
//! cargo run try-runtime \
//! --execution Wasm \
@@ -306,7 +306,7 @@ pub enum Command {
/// Executes the given block against some state.
///
- /// Unlike [`Command:::OnRuntimeUpgrade`], this command needs two inputs: the state, and the
+ /// Unlike [`Command::OnRuntimeUpgrade`], this command needs two inputs: the state, and the
/// block data. Since the state could be cached (see [`State::Snap`]), different flags are
/// provided for both. `--block-at` and `--block-uri`, if provided, are only used for fetching
/// the block. For convenience, these flags can be both emitted, if the [`State::Live`] is
@@ -314,7 +314,7 @@ pub enum Command {
///
/// Note that by default, this command does not overwrite the code, so in wasm execution, the
/// live chain's code is used. This can be disabled if desired, see
- /// [`ExecuteBlockCmd::overwrite_wasm_code`].
+ /// `ExecuteBlockCmd::overwrite_wasm_code`.
///
/// Note that if you do overwrite the wasm code, or generally use the local runtime for this,
/// you might
@@ -326,7 +326,7 @@ pub enum Command {
/// different state transition function.
///
/// To make testing slightly more dynamic, you can disable the state root check by enabling
- /// [`ExecuteBlockCmd::no_check`]. If you get signature verification errors, you should
+ /// `ExecuteBlockCmd::no_check`. If you get signature verification errors, you should
/// manually tweak your local runtime's spec version to fix this.
///
/// A subtle detail of execute block is that if you want to execute block 100 of a live chain
@@ -335,19 +335,19 @@ pub enum Command {
/// If [`State::Snap`] is being used, then this needs to be manually taken into consideration.
///
/// This executes the same runtime api as normal block import, namely `Core_execute_block`. If
- /// [`ExecuteBlockCmd::no_check`] is set, it uses a custom, try-runtime-only runtime
+ /// `ExecuteBlockCmd::no_check` is set, it uses a custom, try-runtime-only runtime
/// api called `TryRuntime_execute_block_no_check`.
ExecuteBlock(commands::execute_block::ExecuteBlockCmd),
/// Executes *the offchain worker hooks* of a given block against some state.
///
- /// Similar to [`Command:::ExecuteBlock`], this command needs two inputs: the state, and the
+ /// Similar to [`Command::ExecuteBlock`], this command needs two inputs: the state, and the
/// header data. Likewise, `--header-at` and `--header-uri` can be filled, or omitted if
/// [`State::Live`] is used.
///
- /// Similar to [`Command:::ExecuteBlock`], this command does not overwrite the code, so in wasm
+ /// Similar to [`Command::ExecuteBlock`], this command does not overwrite the code, so in wasm
/// execution, the live chain's code is used. This can be disabled if desired, see
- /// [`OffchainWorkerCmd::overwrite_wasm_code`].
+ /// `OffchainWorkerCmd::overwrite_wasm_code`.
///
/// This executes the same runtime api as normal block import, namely
/// `OffchainWorkerApi_offchain_worker`.