Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Merged by Bors] - Fix doc_markdown lints in bevy_tasks #3481

Closed
wants to merge 2 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion crates/bevy_tasks/src/countdown_event.rs
Original file line number Diff line number Diff line change
Expand Up @@ -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 {
Expand Down
14 changes: 7 additions & 7 deletions crates/bevy_tasks/src/iter/mod.rs
Original file line number Diff line number Diff line change
Expand Up @@ -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,
Expand All @@ -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
Expand Down
4 changes: 2 additions & 2 deletions crates/bevy_tasks/src/task.rs
Original file line number Diff line number Diff line change
Expand Up @@ -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)
}
Expand Down
10 changes: 5 additions & 5 deletions crates/bevy_tasks/src/task_pool.rs
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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()
}
Expand All @@ -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.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wrong type was documented here

pub fn build(self) -> TaskPool {
TaskPool::new_internal(
self.num_threads,
Expand Down Expand Up @@ -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.
///
Expand Down
6 changes: 3 additions & 3 deletions crates/bevy_tasks/src/usages.rs
Original file line number Diff line number Diff line change
@@ -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`]
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretty sure Compute should be ComputeTaskPool and AsyncCompute should be AsyncComputeTaskPool here, so I fixed that.

//!
//! 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
Expand Down