Rust compiler errors

First moves

# The full explanation, with a worked example. Works offline.
rustc --explain E0499

# One line per diagnostic, for a wall of output.
cargo build --message-format=short

# Count the error codes in a large failure.
cargo build --message-format=json 2>/dev/null | grep -o '"code":{"code":"E[0-9]*"' | sort | uniq -c | sort -rn

Fix the first error, then rebuild. One move or type error produces a cascade downstream, and most of the cascade disappears with the first fix.

Prove the fix

• While you iterate, run cargo check with the same package, features, and target that failed. It reports the same type and borrow errors, faster.
• cargo check checks only library and binary targets. Add --all-targets when the error came from cargo test, a bench, or an example.
• Before you call the error fixed, run the command that failed. cargo check and cargo clippy stop before monomorphization and linking, so they exit 0 on "reached the recursion limit while instantiating" and on linker errors.
• A clean build proves that the types check, not that the behavior is right. Run the test that covers the changed code.

Fixes that compile and hide the bug

Each of these removes the error and keeps the defect. Do not use one to silence a diagnostic.

After three failed attempts at the same error, suspect the design, not the syntax. Stop editing and answer these:

1. Which single component should own this data for its whole lifetime?
2. Does the borrow cross a boundary it should not cross: a thread, an .await, a callback, an FFI call?
3. Would the error disappear if the data were owned rather than borrowed, and what does that cost?

Triage table

The clone reflex

E0382 has one fix that always compiles: .clone(). Treat it as a diagnostic, not a fix. The error stated that two places want the same value. A clone answers "both get one", which is right for a small owned copy and wrong for an identity, a handle, a large buffer, or shared state.

A clone inside a loop compiles, is correct, and allocates once per iteration. See the rust-performance skill.

Borrow conflicts are usually a split problem

E0499 and E0502 rarely need interior mutability. They need the compiler to see that two borrows touch different data: split_at_mut or get_disjoint_mut for indices, field borrows instead of a &self helper, or a copy of the value before the write. Reach for RefCell only after the splits fail (see the hazard table).

Read references/borrow-checker-fixes.md when the first move in the triage table does not fit an E0499, E0502, E0506, E0507, E0716, E0373, E0521, or E0106 error, or to compare the cost of each interior mutability type.

E0282, E0283, E0284, and the never type need a type anchor

These errors mean the available constraints do not select one type. Rust does not infer every method or operator input backward from the final result type. Add the smallest local anchor:

let parsed: u64 = "42".parse()?;
let bytes = Vec::<u8>::new();
let converted = u64::from(7_u8);

Prefer a typed local, a turbofish on the constructor or method that owns the unknown type, or a fully qualified call. Do not change a public return type, add 'static, or add a broad trait bound only to silence inference. Rebuild after the one anchor; later diagnostics can be a cascade from the first unknown type.

An unconstrained generic call as a statement, such as f()?;, has no anchor at all. Edition 2024 falls back to ! instead of (), so the error names the never type:

fn parse_or_default<T: Default>() -> Result<T, ()> { Ok(T::default()) }

fn load() -> Result<(), ()> {
    parse_or_default()?; // the trait bound `!: Default` is not satisfied
    Ok(())
}

The note says "this error might have been caused by changes to Rust's type-inference algorithm". On edition 2021 the same code fails with the deny-by-default lint dependency_on_unit_never_type_fallback (1.92+): "this function depends on never type fallback being ()". Both have one fix. Name the type:

fn parse_or_default<T: Default>() -> Result<T, ()> { Ok(T::default()) }

fn load() -> Result<(), ()> {
    parse_or_default::<()>()?;
    Ok(())
}

let () = parse_or_default()?; also works. Do not allow the lint; it is a hard error on 2024.

E0432 and E0433: unresolved imports

Read the note: and help: lines before you add a dependency. A cargo add line in help: is not a fix (see the hazard table). Stop at the first step that matches:

1. note: found an item that was configured out with "the item is gated behind the f feature". The feature is off. Read the file path under the note.
   • The item is in a dependency: enable its feature with cargo add <crate> --features f, or add f to that dependency's features list. Do not rewrite the import.
   • The item is in this crate: the caller lacks the item's gate. Put the same #[cfg(feature = "f")] on the caller, or build with --features f. Do not add f to default to silence the error; that hides the break in the build without the feature.
2. help: offers a use path ("consider importing") or says "a similar path exists". This covers cannot find type and cannot find value (E0425 or E0433) and E0432. Take that path: std::..., crate::..., or super::.... Check std and this crate before any new crate.
3. The first path segment is a module of this crate: grep -rn 'mod <segment>' src finds it. Write the path from crate:: or super::.

4. The first path segment is a crate that Cargo.toml already lists. The item path is wrong, or the item exists only in another version. Read the source of the version in Cargo.lock, not the documentation of the latest release. Use the package name as Cargo.toml writes it: the path segment tokio_util is the package tokio-util.

   cargo metadata --format-version 1 --locked \
     | jq -r '.packages[] | select(.name == "<package>") | "\(.version) \(.manifest_path)"'

   If jq is not installed, cargo tree -i <package> --locked --depth 0 prints the locked version.

5. The crate is not in Cargo.toml. Add a crate only when the code was written against that crate, or the task asks for a new dependency. Otherwise use std or an existing dependency. Run cargo info <name>: it prints the description, version, rust-version, repository, and features of that exact package, or "could not find". It proves that the name exists, not that it is the crate the code expects. Compare its repository and description with that crate. If they do not match, or the name came only from rustc's help: line, do not add it; ask the user. Otherwise run cargo add <name>.

A Drop impl changes the borrow checker

impl Drop is not a local change. It breaks code that compiled before with E0597, E0502, E0509, or E0184, and no error title names Drop: the drop point is one more use of every borrow the value holds. The note says "... when _g is dropped and runs the Drop code for type Guard". Drop the guard before the read, scope it in an inner block, or keep the type Drop-free. Read the Drop section of references/borrow-checker-fixes.md when an error follows a new impl Drop, or for E0507 inside drop(&mut self).

Related skills

Refer to these by name when they are installed.