Fix doc_markdown lints in bevy_tasks (#3481)

#3457 adds the `doc_markdown` clippy lint, which checks doc comments to make sure code identifiers are escaped with backticks. This causes a lot of lint errors, so this is one of a number of PR's that will fix those lint errors one crate at a time.

This PR fixes lints in the `bevy_tasks` crate.

crates/bevy_tasks/src/countdown_event.rs

@@ -21,7 +21,7 @@ pub struct CountdownEvent {
 }
 
 impl CountdownEvent {
-    /// Creates a CountdownEvent that must be decremented `n` times for listeners to be
+    /// Creates a [`CountdownEvent`] that must be decremented `n` times for listeners to be
     /// signalled
     pub fn new(n: isize) -> Self {
         let inner = CountdownEventInner {

crates/bevy_tasks/src/iter/mod.rs

@@ -3,14 +3,14 @@ use crate::TaskPool;
 mod adapters;
 pub use adapters::*;
 
-/// ParallelIterator closely emulates the std::iter::Iterator
-/// interface. However, it uses bevy_task to compute batches in parallel.
+/// [`ParallelIterator`] closely emulates the `std::iter::Iterator`
+/// interface. However, it uses `bevy_task` to compute batches in parallel.
 ///
-/// Note that the overhead of ParallelIterator is high relative to some
+/// Note that the overhead of [`ParallelIterator`] is high relative to some
 /// workloads. In particular, if the batch size is too small or task being
-/// run in parallel is inexpensive, *a ParallelIterator could take longer
-/// than a normal Iterator*. Therefore, you should profile your code before
-/// using ParallelIterator.
+/// run in parallel is inexpensive, *a [`ParallelIterator`] could take longer
+/// than a normal [`Iterator`]*. Therefore, you should profile your code before
+/// using [`ParallelIterator`].
 pub trait ParallelIterator<B>
 where
     B: Iterator<Item = Self::Item> + Send,
@@ -21,7 +21,7 @@ where
     /// Returns the next batch of items for processing.
     ///
     /// Each batch is an iterator with items of the same type as the
-    /// ParallelIterator. Returns `None` when there are no batches left.
+    /// [`ParallelIterator`]. Returns `None` when there are no batches left.
     fn next_batch(&mut self) -> Option<B>;
 
     /// Returns the bounds on the remaining number of items in the

crates/bevy_tasks/src/task.rs

@@ -12,12 +12,12 @@ use std::{
 /// more gracefully and wait until it stops running, use the [`cancel()`][Task::cancel()] method.
 ///
 /// Tasks that panic get immediately canceled. Awaiting a canceled task also causes a panic.
-/// Wraps async_executor::Task
+/// Wraps `async_executor::Task`
 #[derive(Debug)]
 pub struct Task<T>(async_executor::Task<T>);
 
 impl<T> Task<T> {
-    /// Creates a new task from a given async_executor::Task
+    /// Creates a new task from a given `async_executor::Task`
     pub fn new(task: async_executor::Task<T>) -> Self {
         Self(task)
     }

crates/bevy_tasks/src/task_pool.rs

@@ -10,7 +10,7 @@ use futures_lite::{future, pin};
 
 use crate::Task;
 
-/// Used to create a TaskPool
+/// Used to create a [`TaskPool`]
 #[derive(Debug, Default, Clone)]
 pub struct TaskPoolBuilder {
     /// If set, we'll set up the thread pool to use at most n threads. Otherwise use
@@ -24,7 +24,7 @@ pub struct TaskPoolBuilder {
 }
 
 impl TaskPoolBuilder {
-    /// Creates a new TaskPoolBuilder instance
+    /// Creates a new [`TaskPoolBuilder`] instance
     pub fn new() -> Self {
         Self::default()
     }
@@ -43,13 +43,13 @@ impl TaskPoolBuilder {
     }
 
     /// Override the name of the threads created for the pool. If set, threads will
-    /// be named <thread_name> (<thread_index>), i.e. "MyThreadPool (2)"
+    /// be named `<thread_name> (<thread_index>)`, i.e. `MyThreadPool (2)`
     pub fn thread_name(mut self, thread_name: String) -> Self {
         self.thread_name = Some(thread_name);
         self
     }
 
-    /// Creates a new ThreadPoolBuilder based on the current options.
+    /// Creates a new [`TaskPool`] based on the current options.
     pub fn build(self) -> TaskPool {
         TaskPool::new_internal(
             self.num_threads,
@@ -156,7 +156,7 @@ impl TaskPool {
         self.inner.threads.len()
     }
 
-    /// Allows spawning non-`static futures on the thread pool. The function takes a callback,
+    /// Allows spawning non-`'static` futures on the thread pool. The function takes a callback,
     /// passing a scope object into it. The scope object provided to the callback can be used
     /// to spawn tasks. This function will await the completion of all tasks before returning.
     ///

crates/bevy_tasks/src/usages.rs

@@ -1,9 +1,9 @@
 //! Definitions for a few common task pools that we want. Generally the determining factor for what
 //! kind of work should go in each pool is latency requirements.
 //!
-//! For CPU-intensive work (tasks that generally spin until completion) we have a standard Compute
-//! pool and an AsyncCompute pool. Work that does not need to be completed to present the next
-//! frame should go to the AsyncCompute pool
+//! For CPU-intensive work (tasks that generally spin until completion) we have a standard
+//! [`ComputeTaskPool`]  and an [`AsyncComputeTaskPool`]. Work that does not need to be completed to
+//! present the next frame should go to the [`AsyncComputeTaskPool`]
 //!
 //! For IO-intensive work (tasks that spend very little time in a "woken" state) we have an IO
 //! task pool. The tasks here are expected to complete very quickly. Generally they should just