How to fix error E0433: undeclared crate or module

Short answer: a path used inline — at a call site, not on a use line — does not resolve. The previous page covered E0432, which is the same failure on an import line; E0433 is what you get when the import is missing entirely and the path appears in the body of the code. The compiler walks the path starting from the current module and works outward, so the fix depends on where the name actually lives: the same file, another module, or a crate that Cargo.toml has never heard of.

The error

The most common shape is a std type used with no import at all:

fn main() {
    let mut scores = HashMap::new();
    scores.insert("alice", 10);
    println!("{scores:?}");
}

▶Run this in the Rust Playground

Compiling that with cargo build prints:

error[E0433]: cannot find type `HashMap` in this scope
 --> src/main.rs:2:22
  |
2 |     let mut scores = HashMap::new();
  |                      ^^^^^^^ use of undeclared type `HashMap`
  |
help: consider importing this struct
  |
1 + use std::collections::HashMap;
  |

For more information about this error, try `rustc --explain E0433`.

The headline says cannot find type while the error code is E0433, failed to resolve — the code is the same either way; the headline just describes what the failed segment looked like, and HashMap::new() looked like a type name. The help: block searched the standard library, found exactly one match, and printed the import that fixes it. Accept it:

use std::collections::HashMap;

fn main() {
    let mut scores = HashMap::new();
    scores.insert("alice", 10);
    println!("{scores:?}");
}

▶Run this in the Rust Playground

This prints:

{"alice": 10}

When the path crosses a module boundary

The subtler shape hides inside a project that does declare the module — but declares it in the wrong place relative to the code using it. Module resolution starts in the current module and walks outward, so a name written inside app is looked up in app first, then in app’s ancestors, then among external crates. A sibling of app in the crate root is none of those:

mod settings {
    pub const APP_NAME: &str = "tailer";
}

mod app {
    pub fn banner() -> String {
        format!("[{}]", settings::APP_NAME)
    }
}

fn main() {
    println!("{}", app::banner());
}

▶Run this in the Rust Playground

Compiling that with cargo build prints:

error[E0433]: cannot find module or crate `settings` in this scope
 --> src/main.rs:7:25
  |
7 |         format!("[{}]", settings::APP_NAME)
  |                         ^^^^^^^^ use of unresolved module or unlinked crate `settings`
  |
  = help: if you wanted to use a crate named `settings`, use `cargo add settings` to add it to your `Cargo.toml`
help: consider importing this module
  |
6 +     use crate::settings;
  |

For more information about this error, try `rustc --explain E0433`.

Two help: blocks, and they contradict each other. The first one guesses that settings might be a crates.io crate — it cannot know whether the name was meant to be a module or a dependency, and cargo add settings is not the fix here. The second help block is the one that applies: the module exists at the crate root, one level above the code that named it. Absolute paths with crate:: make that level explicit and never depend on where the code happens to sit:

mod settings {
    pub const APP_NAME: &str = "tailer";
}

mod app {
    pub fn banner() -> String {
        format!("[{}]", crate::settings::APP_NAME)
    }
}

fn main() {
    println!("{}", app::banner());
}

▶Run this in the Rust Playground

This prints:

[tailer]

The same walk explains the wording module or crate: from inside app, a bare settings could legally be either a child module of app or an external crate, and the compiler checked both before giving up. Writing crate::settings removes the ambiguity in the reader’s favour.

One twist to the walk: a bare name also matches the names of the project’s dependencies, so if the module happens to share its name with a crate in Cargo.toml, the same mistake gets a different code — the name resolves to that crate, the constant is not in it, and the error becomes E0425, cannot find value in crate settings. A module named like a dependency is worth avoiding for exactly this reason.

When the crate is not a dependency

The third shape is a first segment that is a crate name, and the project has no such dependency. In a fresh cargo new project with an empty [dependencies] section:

fn main() {
    let data = serde_json::json!({ "ok": true });
    println!("{data}");
}

cargo build prints:

error[E0433]: cannot find module or crate `serde_json` in this scope
 --> src/main.rs:2:16
  |
2 |     let data = serde_json::json!({ "ok": true });
  |                ^^^^^^^^^^ use of unresolved module or unlinked crate `serde_json`

For more information about this error, try `rustc --explain E0433`.
error: could not compile `e0433-demo` (bin "e0433-demo") due to 1 previous error

The last line names the project directory, so a reader’s output ends with their own project’s name. Notice there is no help: block at all this time — nothing in the project or the standard library is named anything like serde_json, so the compiler has no suggestion to offer; on a use line the same missing crate gets a cargo add hint (the E0432 page shows it). Here the fix has to come from the reader: the name is a crate, and crates are declared in Cargo.toml.

cargo add serde_json

      Adding serde_json v1.0.154 to dependencies

The version is whatever the registry resolved when the command ran. The entry it wrote:

[dependencies]
serde_json = "1.0.154"

With the dependency in place, the same code builds and runs:

use serde_json::json;

fn main() {
    let data = json!({ "ok": true });
    println!("{data}");
}

This prints:

{"ok":true}

Not this error

• E0432 — when the same unresolved path appears on a use line instead of inline, the error is unresolved import. The fix is the same edit in a different place, but the two codes have separate pages because the failing line usually is the clue.
• E0425 — when the failing name is a value (a variable, a function, a constant) rather than a path segment, the error is cannot find value in this scope.

Related errors

• How to read a Rust compiler error message
• E0432 — unresolved import