Fix E0364: Trait Bounds on Self Cannot Be Repeated in Where Clause

By Alex Chen
Rust intermediate Linux macOS Windows WebAssembly

1. Symptoms

When the Rust compiler encounters duplicate trait bounds referencing Self in a where clause, it halts compilation and reports error E0364. The compiler produces diagnostic output that clearly identifies the problematic where clause and explains the constraint violation.

The typical error message from rustc reads:

error[E0364]: trait bounds that refer to `Self` may not be repeated in the where clause
 --> src/lib.rs:3:29
  |
3 |     fn method() where Self: Clone, Self: Clone { }
  |                             ^^^^^^^^ second `Self` bound here

In more complex scenarios involving generic parameters, you might see additional context about the trait definition itself:

error[E0364]: trait bounds that refer to `Self` may not be repeated in the where clause
  --> src/lib.rs:5:30
   |
5  | trait MyTrait<T> where Self: Iterator<Item = T>, Self: Iterator<Item = T> {
   |                               ^^^^^^^^^^^^^^^^^^ second `Self` bound here

The error is always accompanied by a caret (^) pointing to the location of the second or subsequent Self bound. The compiler does not specify which bound is the “duplicate” because technically, all identical Self bounds are considered redundant from the language’s perspective.

2. Root Cause

The Rust compiler enforces a fundamental rule regarding trait bounds in where clauses: a trait bound that references Self may only appear once. This restriction exists because the Self type in trait definitions represents the implementing type, and specifying multiple identical bounds provides no additional type constraint information.

When you write where Self: Clone, Self: Clone, the compiler interprets this as attempting to express the same constraint twice. From a type theory standpoint, the second bound contributes nothing that the first bound does not already establish. The Rust language designers chose to reject such redundant declarations at compile time rather than silently accepting them, following the principle that duplicate constraints indicate a potential programming error.

This error commonly arises through several patterns. Accidental duplication when manually writing where clauses accounts for many instances. More insidious cases occur when code generation tools, macros, or procedural macros produce duplicate bounds. When working with complex generic traits that have multiple where clauses spread across different lines or merged during macro expansion, duplicates can slip through unnoticed.

The Self keyword occupies a special position in Rust’s type system. Unlike ordinary type parameters, Self is a contextual alias for “the type that will eventually implement this trait.” Every trait bound involving Self constrains the implementing type in the same way. Repeating such a bound does not create a conjunction of constraintsβ€”it merely states the same constraint twice.

3. Step-by-Step Fix

Resolving E0364 requires removing duplicate Self trait bounds from the where clause. The fix depends on how the duplication occurred.

Scenario 1: Manual Duplication

Inspect the where clause and remove all but one occurrence of each duplicate bound.

Before:

trait Serializable {
    fn serialize(&self) -> Vec<u8>
    where
        Self: Clone,
        Self: Clone,  // Duplicate bound
        Self: serde::Serialize;
}

After:

trait Serializable {
    fn serialize(&self) -> Vec<u8>
    where
        Self: Clone,
        Self: serde::Serialize;
}

Scenario 2: Complex Where Clauses with Multiple Parameters

When your trait involves generic parameters alongside Self bounds, ensure each unique constraint appears exactly once.

Before:

trait Processor {
    type Item;
    
    fn process(self) -> Self::Item
    where
        Self: Iterator,
        Self: Clone,
        Self: Iterator;  // Duplicate Iterator bound
}

After:

trait Processor {
    type Item;
    
    fn process(self) -> Self::Item
    where
        Self: Iterator,
        Self: Clone;
}

Scenario 3: Macro-Generated Duplicates

If a procedural macro or attribute is generating duplicate bounds, you must modify the macro definition or the attributes that invoke it.

Before:

#[some_macro]
trait Conditional: Clone + Clone {  // Macro expanded to duplicate bounds
    fn execute();
}

After:

#[some_macro]
trait Conditional: Clone {  // Ensure macro receives correct input
    fn execute();
}

Scenario 4: Merged Where Clauses

When combining where clauses from multiple sources, verify that no Self bounds are duplicated.

Before:

use std::fmt::Debug;

trait Validator
where
    Self: Debug,
{
    type Error;
    
    fn validate(self) -> Result<(), Self::Error>
    where
        Self: Clone;  // Separate where clause with Clone
}

After:

use std::fmt::Debug;

trait Validator
where
    Self: Debug,
{
    type Error;
    
    fn validate(self) -> Result<(), Self::Error>
    where
        Self: Clone;
}

4. Verification

After applying the fix, recompile your crate to confirm the error has been resolved. Run the standard build command for your project type:

cargo build

A successful compilation produces no E0364 error, and the output should indicate that compilation completed normally:

   Compiling my_crate v0.1.0 (path/to/my_crate)
    Finished dev [unoptimized + debuginfo] target(s) in 0.52s

Beyond basic compilation, verify that your trait’s functionality remains intact by running tests:

cargo test

Ensure that any types implementing the corrected trait continue to work as expected. If your trait defines method signatures with the where clause, test concrete implementations:

#[cfg(test)]
mod tests {
    use super::*;

    struct MyType(String);

    impl Serializable for MyType {
        fn serialize(&self) -> Vec<u8> {
            self.0.as_bytes().to_vec()
        }
    }

    #[test]
    fn test_serialization() {
        let value = MyType("hello".to_string());
        let data = value.serialize();
        assert_eq!(data, b"hello");
    }
}

For library crates, consider running cargo clippy to catch any remaining style issues or potential duplicates that might have been missed:

cargo clippy -- -W clippy::all

5. Common Pitfalls

When addressing E0364, developers frequently encounter several recurring issues that can complicate the fix or lead to new errors.

Removing the Wrong Bound: When multiple distinct Self bounds exist, ensure you remove duplicates rather than legitimate unique bounds. For instance, Self: Clone and Self: Debug are distinct constraints and should both remain.

Overcorrection in Generic Traits: In traits with associated types and generic parameters, be cautious about which bounds you retain. The following is incorrect because it removes a necessary bound:

// WRONG - removed Debug but kept Clone twice (conceptually)
trait BadExample where Self: Clone, Self: Clone { }

Confusing Supertraits with Where Bounds: Remember that trait MyTrait: ParentTrait declares a supertrait, which is semantically equivalent to where Self: ParentTrait. Both forms can contribute to E0364 if duplicated:

// This also triggers E0364
trait Duplicate: Clone + Clone { }

Macro Expansion Blind Spots: When using derive macros or custom procedural macros, the generated code may contain duplicates that are invisible in your source. Use cargo expand to inspect the macro output:

cargo install cargo-expand
cargo expand

Examine the expanded code to identify where the macro introduces duplicate Self bounds.

Merge Conflicts in Version Control: When resolving merge conflicts involving trait definitions, ensure that duplicate bounds from both branches are deduplicated rather than combined. A conflict resolution that retains both versions of a where clause will produce E0364.

Error E0364 belongs to a family of trait-related compiler errors that deal with Self type constraints and where clause semantics.

E0393: The type parameter must be listed First in Parameterized Trait Definitions

This error occurs when a generic type parameter appears before Self in the trait definition’s parameter list. Unlike E0364, which addresses duplication, E0393 concerns ordering:

// E0393: type parameter `T` must be listed before `Self`
trait WrongOrder<T, Self> { }  // Invalid syntax

E0407: Method Has An Invalid Receiver Type

This error relates to method signatures with improper self parameters, particularly in trait implementations:

impl Trait for Type {
    fn method(self: &Self) { }  // E0407: invalid receiver type
}

E0053: Method Has a Different Number of Generic Parameters Than Its Trait

This error surfaces when the number of generic parameters in an implementation differs from the trait definition, which can sometimes accompany where clause issues:

trait Example<T> { fn method<U>(&self, x: U); }

impl Example<u32> for MyType {
    fn method(&self, x: u8) { }  // E0053: missing generic parameter U
}

Understanding the relationships between these errors helps developers navigate Rust’s trait system more effectively. E0364 specifically targets the constraint that Self bounds in where clauses must be unique, distinguishing it from errors related to trait structure, method signatures, or generic parameter counts.

rust e0364 where-clause trait-bounds self compiler-error