From b32770d3033e7ece27768f545fbdf55c221c2a67 Mon Sep 17 00:00:00 2001 From: Michael Dorst Date: Wed, 29 Dec 2021 17:38:13 +0000 Subject: [PATCH] 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 | 2 +- crates/bevy_tasks/src/iter/mod.rs | 14 +++++++------- crates/bevy_tasks/src/task.rs | 4 ++-- crates/bevy_tasks/src/task_pool.rs | 10 +++++----- crates/bevy_tasks/src/usages.rs | 6 +++--- 5 files changed, 18 insertions(+), 18 deletions(-) diff --git a/crates/bevy_tasks/src/countdown_event.rs b/crates/bevy_tasks/src/countdown_event.rs index 9f672fe16ba0b..eceef9697cd1a 100644 --- a/crates/bevy_tasks/src/countdown_event.rs +++ b/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 { diff --git a/crates/bevy_tasks/src/iter/mod.rs b/crates/bevy_tasks/src/iter/mod.rs index 91147fceb1acf..bebc1c0792e2c 100644 --- a/crates/bevy_tasks/src/iter/mod.rs +++ b/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 where B: Iterator + 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; /// Returns the bounds on the remaining number of items in the diff --git a/crates/bevy_tasks/src/task.rs b/crates/bevy_tasks/src/task.rs index 461ed36e0e8b4..eb257080b4207 100644 --- a/crates/bevy_tasks/src/task.rs +++ b/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(async_executor::Task); impl Task { - /// 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) -> Self { Self(task) } diff --git a/crates/bevy_tasks/src/task_pool.rs b/crates/bevy_tasks/src/task_pool.rs index 9331799120583..bf23ef1a586c9 100644 --- a/crates/bevy_tasks/src/task_pool.rs +++ b/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 (), i.e. "MyThreadPool (2)" + /// be named ` ()`, 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. /// diff --git a/crates/bevy_tasks/src/usages.rs b/crates/bevy_tasks/src/usages.rs index 7adf60639b116..923c1a7eb4eab 100644 --- a/crates/bevy_tasks/src/usages.rs +++ b/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