Compiler und Fehlerlesen

Anatomie einer rustc-Fehlermeldung

Eine typische Meldung sieht so aus:

error[E0382]: borrow of moved value: `s`
 --> src/main.rs:5:20
  |
3 |     let s = String::from("Hallo");
  |         - move occurs because `s` has type `String`, which does not implement the `Copy` trait
4 |     consume(s);
  |             - value moved here
5 |     println!("{}", s);
  |                    ^ value borrowed here after move
  |
  = note: `consume` takes ownership of `s` because `String` does not implement `Copy`
  = help: consider cloning the value if the performance cost is acceptable: `s.clone()`

Diese Meldung hat sieben strukturelle Bauteile, und jedes davon hilft:

1. error vs. warning — der Schweregrad. warning führt nicht zum Build-Abbruch (außer du erzwingst es mit -D warnings).
2. [E0382] — der Error-Code. Eindeutig pro Fehlerart, recherchierbar mit rustc --explain E0382.
3. borrow of moved value: \s`` — die Hauptaussage in einem Satz. Was ist konzeptuell falsch.
4. --> src/main.rs:5:20 — die primäre Stelle: Datei, Zeile, Spalte.
5. Code-Snippet mit ^-Markern — der primary span. Die Stelle, an der der Fehler wirklich auftritt, plus Kontext-Zeilen.
6. note: — Hintergrund. Warum genau der Compiler die Operation ablehnt.
7. help: und suggestion: — Lösungsvorschläge. Manchmal sogar mit konkretem Diff (note: this can be a Foo<T> if you do X).

Der entscheidende Reflex: immer von oben nach unten lesen. Erst der Error-Code-Satz, dann die Stelle, dann die note, dann die help. Oft braucht man die help-Zeile nicht — die note macht den Fehler schon verständlich.

Mit --explain mehr lernen

Für jeden Error-Code gibt es eine ausführliche Erklärung:

rustc --explain E0382

Das öffnet eine mehrere Absätze lange Erklärung mit Beispiel-Code und Lösung. Bei Konzepten wie Ownership, Lifetimes oder Trait-Bounds extrem lehrreich — wer fünf solche Erklärungen liest, hat ein Drittel des Lernpensums hinter sich.

Die wichtigsten Error-Codes für Einsteiger

E0382 — borrow/use of moved value

Du hast einen Wert in eine Funktion (oder Variable) gemoved und versuchst danach, ihn nochmal zu verwenden.

fn main() {
    let s = String::from("Hallo");
    consume(s);
    println!("{}", s);   // E0382 — s wurde gemoved
}

fn consume(_text: String) {}

Lösungen je nach Intent:

• Wenn die Funktion den Wert nur lesen muss: per Referenz übergeben (consume(&s), Signatur fn consume(text: &String)).
• Wenn beide den Wert brauchen: klonen (consume(s.clone())) — verständlich teuer.
• Wenn du tatsächlich Ownership übergeben willst und danach nicht mehr brauchst: den println! weglassen.

E0502 — cannot borrow as mutable / as immutable

Du hast gleichzeitig eine shared (&) und eine mutable (&mut) Referenz im selben Scope.

fn main() {
    let mut v = vec![1, 2, 3];
    let first = &v[0];        // shared borrow
    v.push(4);                // E0502 — mutable borrow nicht erlaubt
    println!("{}", first);
}

Rust verbietet Aliasing-und-Mutation gleichzeitig. Das ist der Kern der Memory-Safety-Garantie. Lösungen:

• Den shared-Borrow vor dem mutable-Aufruf droppen (z. B. den println! davor verschieben, sodass first nach push nicht mehr gebraucht wird — NLL erkennt das ab Edition 2018).
• Den Wert klonen statt referenzieren: let first = v[0].clone();.

E0507 — cannot move out of a borrowed value

Du versuchst, einen Wert aus einer Referenz herauszunehmen — was unmöglich ist, weil der Eigentümer dann ein leeres Loch hätte.

struct Container { data: String }

fn extract(c: &Container) -> String {
    c.data            // E0507 — data ist hinter &Container
}

Lösungen:

• Klonen: c.data.clone().
• Den Container by-value annehmen: fn extract(c: Container) -> String { c.data }.
• Bei mutable Borrow: std::mem::take(&mut c.data) ersetzt mit dem Default-Wert.

E0596 — cannot borrow as mutable

Du versuchst, eine &mut-Referenz von einer immutable Variable zu nehmen.

fn main() {
    let v = vec![1, 2, 3];     // ohne `mut`
    v.push(4);                 // E0596 — v ist nicht mutable
}

Lösung: let mut v = ...;. Der Compiler-Suggestion-Block sagt das auch direkt.

E0308 — mismatched types

Der Klassiker. Du hast einen Wert vom Typ A, der Compiler erwartet Typ B.

fn addiere(a: i32, b: i32) -> i32 {
    a + b;            // E0308 — Semikolon macht aus a+b den Wert ()
}

Der note: implicitly returns () as its body has no tail expression weist dich auf das Semikolon hin.

Mehrere Fehler gleichzeitig

rustc bricht nicht beim ersten Fehler ab — er sammelt mehrere und zeigt sie zusammen. Mit cargo build siehst du oft fünf, zehn Diagnosen auf einmal.

Strategie:

1. Immer von oben nach unten beheben. Spätere Fehler folgen oft aus früheren (eine fehlende Variable führt zu allen ihren Verwendungs-Stellen, die auch melden).
2. Nach jedem Fix neu bauen. Nicht versuchen, drei Fehler gleichzeitig im Kopf zu lösen — der nächste Build zeigt dir, ob die Top-Fehler verschwunden sind und welche neuen Fehler aufgetaucht sind.
3. cargo check statt cargo build während du fixt. Faktor 5–10 schneller, weil keine Binary erzeugt wird.

warnings: ernst nehmen, ernst lassen

Warnings vom Compiler sind in Rust deutlich besser kuratiert als in C oder C++. Wenn rustc warnt, hat das meistens einen guten Grund. Häufige Beispiele:

• unused_variables — du hast eine Variable angelegt, aber nie gelesen. Wenn das Absicht ist (z. B. bei einem Function-Parameter, der noch nicht genutzt wird), präfixe sie mit _: _unused.
• unused_must_use — du ignorierst einen Wert (typischerweise ein Result), den der Compiler für wichtig hält. Lösung: entweder mit let _ = ... explizit ignorieren oder behandeln.
• dead_code — eine Funktion oder ein Modul wird nirgendwo aufgerufen. Im Library-Code oft falsch positiv (sie wird ja von externen Crates aufgerufen) — dann mit pub markieren oder mit #[allow(dead_code)] explizit erlauben.

In CI: cargo build -- -D warnings macht alle Warnings zu Errors. Das verhindert, dass sich Warnings im Code anlagern.

Clippy — der Linter, der unterrichtet

cargo clippy ist mehr als ein Linter — es ist ein Lehrmittel. Über 700 Lints, jeder mit einer kurzen Erklärung, viele mit automatischer Korrektur.

cargo clippy                          # Standard-Lints
cargo clippy -- -W clippy::pedantic   # Pedantischer Modus, viele Hinweise mehr
cargo clippy --fix                    # Wo möglich, automatisch fixen

Beispiel-Lint:

warning: this `if let` can be collapsed into the outer `match`
 --> src/main.rs:8:5
  |
8 |     if let Some(x) = opt { println!("{x}"); }
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
help: replace it with this
  |
8 |     opt.map(|x| println!("{x}"));
  |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~
  |
  = note: `#[warn(clippy::manual_map)]` on by default

Jeder Lint hat einen Namen (clippy::manual_map), eine Begründung im Lint-Verzeichnis und oft eine spielbare Korrektur. Du kannst einzelne Lints lokal abschalten:

#[allow(clippy::manual_map)]
fn main() {
    // ...
}

Für die Code-Qualität in einem Projekt ist es empfehlenswert, cargo clippy -- -D warnings in CI laufen zu lassen. Wer Clippy von Anfang an ernst nimmt, lernt schneller idiomatisches Rust als jeder, der nur rustc-Errors fixt.

rust-analyzer in der IDE

In VS Code, Neovim, Helix oder JetBrains übernimmt rust-analyzer die rustc-Diagnostik live während du tippst. Was er zeigt:

• Inline-Errors und -Warnings — kein Build nötig.
• Type-Hints: über jeder let-Bindung kannst du den inferred Typ einblenden.
• Inlay-Hints für Closure-Parameter, generische Argumente, Iterator-Adapter.
• Hover-Doku: Mauszeiger über einen Identifier zeigt seine Doc-Kommentare.
• Quick Fixes: viele rustc-Suggestions sind als Ein-Klick-Action verfügbar.
• Go-to-Definition auch in std hinein, wenn rust-src installiert ist.

Rust ohne rust-analyzer ist möglich, aber etwa wie TypeScript ohne tsserver — funktioniert, lässt aber viel Arbeitserleichterung liegen.

cargo expand — Makros sichtbar machen

Wenn du eine Makro-Expansion verstehen willst (z. B. was #[derive(Debug)] oder println! wirklich generiert), nutze das Tool cargo-expand:

cargo install cargo-expand          # einmalig
cargo expand                        # Gesamtes Crate
cargo expand --bin meine-app
cargo expand --lib path::to::module

Sehr nützlich, wenn ein derive-Makro ungewöhnliches Verhalten zeigt oder du selbst proc-macros baust. Auch unentbehrlich beim Lesen von Crates, die intensiv mit Makros arbeiten (z. B. serde, tokio).

cargo check vs. cargo build im Workflow

Wiederholung, weil so wichtig:

Empfohlenes Live-Setup:

cargo install cargo-watch
cargo watch -x check                              # Bei jeder Datei-Änderung check
cargo watch -x check -x test                      # check + test
cargo watch -x 'clippy -- -D warnings'            # Strenge Lints

cargo-watch startet bei jeder Datei-Änderung neu — du tippst, speicherst, und siehst sofort, ob du etwas kaputt gemacht hast. Faktor 10 für die Lernkurve.

Weiterführende Ressourcen

Externe Quellen

• rustc Error Index – alle Error-Codes mit Erklärung
• The rustc Book – Lints
• Clippy Lint Verzeichnis
• rust-analyzer User Manual
• cargo-expand auf GitHub
• cargo-watch auf GitHub

Verwandte Artikel

• Editionen 2015 / 2018 / 2021 / 2024
• Projektstruktur
• Cargo-Grundlagen
• Erstes Programm
• Grundlagen-Übersicht