From eb3e8150f0084bb4f8fb0562e089f68f8bb353ee Mon Sep 17 00:00:00 2001 From: findseat Date: Sat, 6 Apr 2024 10:06:53 +0800 Subject: [PATCH] chore: fix some comments Signed-off-by: findseat --- crates/turbo-tasks-memory/src/aggregation_tree/mod.rs | 2 +- crates/turbo-tasks/src/state.rs | 2 +- crates/turbo-tasks/src/task/function.rs | 2 +- docs/pages/repo/docs/core-concepts/monorepos/task-graph.mdx | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/crates/turbo-tasks-memory/src/aggregation_tree/mod.rs b/crates/turbo-tasks-memory/src/aggregation_tree/mod.rs index cb5e449176772..fd6e81a14e6a5 100644 --- a/crates/turbo-tasks-memory/src/aggregation_tree/mod.rs +++ b/crates/turbo-tasks-memory/src/aggregation_tree/mod.rs @@ -1,6 +1,6 @@ //! The module implements a datastructure that aggregates a "forest" into less //! nodes. For any node one can ask for a single aggregated version of all -//! children on that node. Changes the the forest will propagate up the +//! children on that node. Changes the forest will propagate up the //! aggregation tree to keep it up to date. So asking of an aggregated //! information is cheap and one can even wait for aggregated info to change. //! diff --git a/crates/turbo-tasks/src/state.rs b/crates/turbo-tasks/src/state.rs index 072a2558729b1..d2346ba103fe1 100644 --- a/crates/turbo-tasks/src/state.rs +++ b/crates/turbo-tasks/src/state.rs @@ -54,7 +54,7 @@ impl Eq for State {} impl Serialize for State { fn serialize(&self, _serializer: S) -> Result { - // For this to work at all we need to do more. Changing the the state need to + // For this to work at all we need to do more. Changing the state need to // invalidate the serialization of the task that contains the state. So we // probably need to store the state outside of the task to be able to serialize // it independent from the creating task. diff --git a/crates/turbo-tasks/src/task/function.rs b/crates/turbo-tasks/src/task/function.rs index 1a15f24f69585..b753f468158b8 100644 --- a/crates/turbo-tasks/src/task/function.rs +++ b/crates/turbo-tasks/src/task/function.rs @@ -12,7 +12,7 @@ //! work, but they are described in this blog post: //! https://blog.logrocket.com/rust-bevy-entity-component-system/ //! -//! However, there are is an additional complication in our case: async methods +//! However, there is an additional complication in our case: async methods //! that accept a reference to the receiver as their first argument. //! //! This complication handled through our own version of the `async_trait` diff --git a/docs/pages/repo/docs/core-concepts/monorepos/task-graph.mdx b/docs/pages/repo/docs/core-concepts/monorepos/task-graph.mdx index 3f66a5c827153..04db040e96722 100644 --- a/docs/pages/repo/docs/core-concepts/monorepos/task-graph.mdx +++ b/docs/pages/repo/docs/core-concepts/monorepos/task-graph.mdx @@ -12,7 +12,7 @@ Graph. Turborepo uses a data structure called a [directed acyclic graph (DAG)][1] to understand your repository and its tasks. A graph is made up of "nodes" and -"edges". In our Task Graph, the nodes are tasks and the edges are the the +"edges". In our Task Graph, the nodes are tasks and the edges are the dependencies between tasks. A _directed_ graph indicates that the edges connecting each node have a direction, so if Task A points to Task B, we can say that Task A depends on Task B. The direction of the edge depends on which task