Skip to content
Select theme

How to fix error E0599: no method named X found for type Y

Short answer: the compiler knows what type the receiver is, and there is no method with that name it is allowed to call on it. There are four ways to get there, and the diagnostic itself says which one you hit: the method lives in a trait that is not in scope (import the trait), the method exists but your type does not implement the trait that provides it (derive or implement it), the method belongs to another type in the chain — usually an iterator (convert first), or it is a spelling mistake (the compiler names the close match). Unlike E0277, which fires on trait bounds in generic code, E0599 is always about one specific method call: a name, a dot, and a receiver that does not have it.

The everyday version: a method that the standard library genuinely provides, called on a type that genuinely has it — and it still does not compile.

Compiling that with cargo build prints:

error[E0599]: no method named `read_to_string` found for reference `&[u8]` in the current scope
--> src/main.rs:4:10
|
4 | data.read_to_string(&mut s).unwrap();
| ^^^^^^^^^^^^^^
|
::: /Users/rango/.rustup/toolchains/1.99.0-aarch64-apple-darwin/lib/rustlib/src/rust/library/alloc/src/io/read.rs:342:8
|
342 | fn read_to_string(&mut self, buf: &mut String) -> Result<usize> {
| -------------- the method is available for `&[u8]` here
|
= help: items from traits can only be used if the trait is in scope
help: trait `Read` which provides `read_to_string` is implemented but not in scope; perhaps you want to import it
|
1 + use std::io::Read;
|
help: there is a method `read_to_end` with a similar name
|
4 - data.read_to_string(&mut s).unwrap();
4 + data.read_to_end(&mut s).unwrap();
|
For more information about this error, try `rustc --explain E0599`.

Read the help block before anything else, because this one error carries both an accusation and an exoneration. The middle of the message says the method is available for &[u8] — the signature is right there in the standard library, fn read_to_string(&mut self, buf: &mut String). Nothing is wrong with the call. The problem is the last line of the chain:

items from traits can only be used if the trait is in scope

read_to_string is not defined on &[u8] directly. It is a method of the Read trait, which the standard library implements for &[u8] — and unlike Clone, Debug, or Iterator, the Read trait is not in the prelude. Until you use it, its methods are invisible, no matter how correct the call is. The compiler even shows the exact line to add: use std::io::Read;.

(The last help, read_to_end with a similar name, is a real method and a real dead end — it fills the buffer with bytes instead of building a String. When a trait hint and a similar-name hint both appear, the trait hint is the one to read.)

This prints:

hello, reader

One import, and the method that was already there becomes callable. (data is now mut because read_to_string takes &mut self — reading consumes the slice’s cursor.) The same rule explains the other classic members of this family: write! and writeln! on a Vec<u8> or a File need use std::io::Write;, and read_to_string on a File needs the same std::io::Read this page started with. The type is never the problem; the trait being in scope is.

Second shape, and the message reads differently. clone is in scope — it comes with the prelude — so this cannot be a missing import. What is missing is the implementation:

Compiling that with cargo build prints:

error[E0599]: no method named `clone` found for struct `Point` in the current scope
--> src/main.rs:5:15
|
1 | struct Point { x: i32, y: i32 }
| ------------ method `clone` not found for this struct
...
5 | let q = p.clone();
| ^^^^^ method not found in `Point`
|
= help: items from traits can only be used if the trait is implemented and in scope
= note: the following trait defines an item `clone`, perhaps you need to implement it:
candidate #1: `Clone`
For more information about this error, try `rustc --explain E0599`.

Two differences from the first error are worth reading closely. The word “implemented” has joined “in scope”: the trait is imported, so now the question is whether Point has an impl. And the note names the candidate — Clone is the trait that defines clone, and Point does not implement it. A struct gets Clone either by deriving it or by writing the impl by hand; deriving is the ordinary choice:

This prints:

1

The same shape fires for every method with a trait behind it called on a type that does not implement that trait: .iter() on something that is not a collection, .to_string() on a type whose owner never derived Display. The note always names the trait — implementing or deriving it is the fix, and if the type is not yours to change, the fix is a different method or an explicit conversion.

The method belongs to another type in the chain

Section titled “The method belongs to another type in the chain”

Third shape. The method is real, the trait is in scope, the type implements everything — the method simply lives on a different type than the one you called it on:

Compiling that with cargo build prints:

error[E0599]: no method named `map` found for struct `Vec<{integer}>` in the current scope
--> src/main.rs:3:21
|
3 | let doubled = v.map(|x| x * 2);
| ^^^ `Vec<{integer}>` is not an iterator
|
help: call `.into_iter()` first
|
3 | let doubled = v.into_iter().map(|x| x * 2);
| ++++++++++++
For more information about this error, try `rustc --explain E0599`.

map is a method of Iterator, and a Vec is not an iterator — it is a thing you can turn into one. The compiler’s suggestion is the fix this time: convert, then map.

This prints:

[2, 4, 6]

into_iter consumes the vector. If the rest of the function still needs v, convert with .iter() instead, which borrows and yields references — the closures differ accordingly:

This prints the same [2, 4, 6]. Whenever an iterator-chain method shows up under E0599, look at the receiver: nine times out of ten the chain is missing its .iter() / .into_iter() step, or a collect in the middle turned the iterator back into a collection.

Fourth shape, no lesson required:

Compiling that with cargo build prints:

error[E0599]: no method named `toupper` found for struct `String` in the current scope
--> src/main.rs:3:22
|
3 | println!("{}", s.toupper());
| ^^^^^^^
|
help: there is a method `to_uppercase` with a similar name
|
3 - println!("{}", s.toupper());
3 + println!("{}", s.to_uppercase());
|
For more information about this error, try `rustc --explain E0599`.

This is the one shape where the plain meaning of the headline is the whole story — the name is wrong — and the similar name help is the fix. Take the suggestion when it is the method you meant.

The headline is always no method named ... found for type ..., so the help block is where the diagnosis lives. The four variants, and what each one asks of you:

  • “trait X which provides Y is implemented but not in scope” — an import problem. Add the use, change nothing else.
  • “the following trait defines an item Y, perhaps you need to implement it: candidate #1: X” — an implementation problem. The trait is in scope; your type lacks the impl. Derive it or write it, or call a different method.
  • “T is not an iterator” (often with “call .into_iter() first”) — the method belongs to Iterator; convert the receiver first.
  • “there is a method Z with a similar name” — a typo, most of the time. Take the suggestion if Z is what you meant; ignore it if the trait hint above it is the real answer.
  • the trait bound is not satisfied — E0277. E0599 is about a concrete method call that cannot be resolved; E0277 is about a trait bound written into a generic signature that some type fails to meet. They are cousins — the same missing impl can produce either, depending on whether the call went through a method name or a where clause.
  • cannot find value in this scope — E0425. That one is a bare name with no dot before it: a function, a variable, a module path. E0599 always has a receiver on the left of the dot.