Skip to content
Select theme

How to fix error E0432: unresolved import

Short answer: a path on a use line does not resolve. The compiler reads the path segment by segment, and the first one it cannot find is the one the error names — a misspelled name, a module that does not exist, or a crate the project has never declared. If the path is right and the item behind it is merely private, that is a different code: E0603, covered at the end of this page.

A use line is only a path, so E0432 is a path error — it is about the import line itself, not about a name used somewhere in the body of the code (that is E0425). The most common shape is the typo, and the most common place for one is a std path typed from memory:

Compiling that with cargo build prints:

error[E0432]: unresolved import `std::collections::Hashmap`
--> src/main.rs:1:5
|
1 | use std::collections::Hashmap;
| ^^^^^^^^^^^^^^^^^^-------
| |
| no `Hashmap` in `collections`
|
help: a similar name exists in the module
|
1 - use std::collections::Hashmap;
1 + use std::collections::HashMap;
|
For more information about this error, try `rustc --explain E0432`.

The compiler walked the path one segment at a time: std resolved, collections resolved, and Hashmap does not exist there — no Hashmap in collections. As with E0425, the help: block compares the unknown name against what the module actually exports, and here the suggestion is the fix itself. Accept it:

This prints:

{"alice": 10}

The same segment-by-segment read applies to paths into the project’s own modules. A typo in the middle of one fails exactly the same way:

error[E0432]: unresolved import `crate::confg`
--> src/main.rs:5:12
|
5 | use crate::confg::APP_NAME;
| ^^^^^ could not find `confg` in the crate root
For more information about this error, try `rustc --explain E0432`.

Two details differ from the std case. The message names the whole import (crate::confg) and points at the segment that failed — confg, at column 12, one character past crate::. And there is no help: block this time: the compiler found nothing close enough to offer, so the fix comes from comparing the path against the mod declarations by hand. The module is called config; make the path match:

This prints:

starting tailer

The third shape is the one the compiler can blame on the project rather than on the path: the first segment of the import is a crate name, and the project has no such dependency. In a fresh cargo new project with an empty [dependencies] section:

use serde::Serialize;
fn main() {
fn assert_serializable<T: Serialize>(_: &T) {}
let retries = 5;
assert_serializable(&retries);
println!("retries is serializable");
}

cargo build prints:

error[E0432]: unresolved import `serde`
--> src/main.rs:1:5
|
1 | use serde::Serialize;
| ^^^^^ use of unresolved module or unlinked crate `serde`
|
= help: if you wanted to use a crate named `serde`, use `cargo add serde` to add it to your `Cargo.toml`
For more information about this error, try `rustc --explain E0432`.
error: could not compile `e0432-crate2` (bin "e0432-crate2") due to 1 previous error

The wording shifts — unresolved module or unlinked crate instead of no X in Y — because at this point the compiler cannot tell whether serde was meant to be a crate or a module of this project; it only knows nothing by that name is reachable. The final line names the project directory, so a reader’s output ends with their own project’s name.

The help: block names the fix. cargo add looks the crate up on crates.io and writes the dependency into Cargo.toml:

Terminal window
cargo add serde
Adding serde v1.0.229 to dependencies

The version is whatever the registry resolved when the command ran — a project created later will pin a newer one. The entry it wrote:

[dependencies]
serde = "1.0.229"

With the dependency in place, the same src/main.rs builds clean:

Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.51s

The sneakiest neighbour of E0432 looks identical from the reader’s side — a use line refuses to compile — but it gets a different code. When the path resolves completely and the item at the end of it simply is not pub:

error[E0603]: constant `SECRET` is private
--> src/main.rs:5:20
|
5 | use crate::config::SECRET;
| ^^^^^^ private constant
|
note: the constant `SECRET` is defined here
--> src/main.rs:2:5
|
2 | const SECRET: &str = "hunter2";
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For more information about this error, try `rustc --explain E0603`.

This import is not unresolved — the compiler resolved the path all the way to its definition, and the definition says const SECRET with no pub, which makes it visible only inside config. A private module produces the same shape (module secrets is private instead of constant SECRET is private). The fix is visibility, not the path:

This prints:

connecting with hunter2
  • E0425 — when the failing name is a value used in the body of the code (a variable, a constant, a function) rather than a path on a use line, the error is cannot find value in this scope.
  • E0433 — when a path is used at a call site with no use at all (Hashmap::new() with the import missing entirely), the error is E0433, failed to resolve.
  • E0603 — when the path resolves but the item behind it is private, as shown above.