chore: remove repetitive words

crates/turbo-tasks-hash/src/xxh3_hash64.rs

@@ -20,13 +20,13 @@ impl Xxh3Hash64Hasher {
         Self(xxh3::Hash64::with_seed(0))
     }
 
-    /// Uses the DeterministicHash trait to to hash the input in a
+    /// Uses the DeterministicHash trait to hash the input in a
     /// cross-platform way.
     pub fn write_value<T: DeterministicHash>(&mut self, input: T) {
         input.deterministic_hash(self);
     }
 
-    /// Uses the DeterministicHash trait to to hash the input in a
+    /// Uses the DeterministicHash trait to hash the input in a
     /// cross-platform way.
     pub fn write_ref<T: DeterministicHash>(&mut self, input: &T) {
         input.deterministic_hash(self);

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.
 //!

crates/turbo-tasks/src/state.rs

@@ -54,7 +54,7 @@ impl<T> Eq for State<T> {}
 
 impl<T> Serialize for State<T> {
     fn serialize<S: serde::Serializer>(&self, _serializer: S) -> Result<S::Ok, S::Error> {
-        // 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.

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`

docs/pages/repo/docs/core-concepts/monorepos/running-tasks.mdx

@@ -171,7 +171,7 @@ opt in those tasks which don't themselves trigger a `turbo` run that would recur
 
 After you've declared a task in `turbo.json`, it's up to you to implement it in
 your `package.json` manifests. You can add scripts all at once, or one workspace
-at at a time. Turborepo will gracefully skip workspaces that don't include the
+at a time. Turborepo will gracefully skip workspaces that don't include the
 task in their respective package.json manifest.
 
 For example, if your repository has the three workspaces (similar to the ones mentioned above):