Nie-Leksikalne Czasy Życia (NLL) wykorzystują analizę przepływu danych opartą na grafie przepływu sterowania (CFG), która oblicza żywotność pożyczonych danych na poziomie MIR. Zamiast przywiązywać czasy życia pożyczek do zakresów leksykalnych, kompilator konstruuje CFG, w którym węzły reprezentują punkty programu. Pożyczka jest aktywna tylko na ścieżkach od momentu jej utworzenia do ostatniego użycia, co jest określane przez analizę przepływu danych wstecz. To pozwala kompilatorowi akceptować programy, w których mutowalna pożyczka zaczyna się po ostatnim użyciu niemutowalnej pożyczki, nawet w tym samym bloku. Analiza odrzuca programy, w których jakakolwiek ścieżka mogłaby prowadzić do użycia po zwolnieniu, zapewniając bezpieczeństwo przy jednoczesnym dopuszczeniu wcześniej odrzuconych poprawnych programów.
Problem: W systemie telemetrycznym o dużej przepustowości funkcja przeszukiwała bufor pakietów w celu walidacji sum kontroli (niemutowalna pożyczka), a następnie natychmiast naprawiała uszkodzone pakiety (mutowalna pożyczka). Przed rokiem 2018 Rust egzekwował leksykalne czasy życia, co powodowało, że niemutowalna pożyczka trwała do końca funkcji, blokując mutowalne naprawy.
Rozwiązanie 1: Jawne klonowanie. Skopiuj cały bufor przed walidacją, aby zwolnić oryginalną pożyczkę, a następnie zmień kopię. To podejście jest proste i zgodne z dawnymi wersjami Rust. Jednak wiąże się z podwójnym zużyciem pamięci i opóźnieniem alokacji, co jest niedopuszczalne w systemie przetwarzającym ruch gigabitowy, gdzie budżety opóźnień są mierzone w mikrosekundach.
Rozwiązanie 2: Przebudowa leksykalna. Umieść pętlę walidacyjną wewnątrz zagnieżdżonego bloku { ... }, aby wymusić zakończenie niemutowalnej pożyczki przed sekcją mutowalnej naprawy. To unika narzutu czasowego i działa bez aktualizacji języka. Jednak prowadzi do zamieszania w kodzie, fragmentując logiczny przepływ „waliduj, a następnie napraw” w zagnieżdżonych zakresach i komplikując obsługę błędów, które obejmują obie fazy.
Rozwiązanie 3: Przyjęcie NLL. Migracja do Rust 2018 w celu wykorzystania analizy przepływu danych, pozwalająca pożyczkom kończyć się w ostatnim punkcie użycia, a nie w otaczającej klamrze. To zapewnia abstrakcję o zerowych kosztach, gdzie kod jest czytany jako liniowa sekwencja bez zagnieżdżenia czy klonowania. Kompilator akceptuje program, ponieważ analiza dowodzi, że niemutowalna pożyczka jest martwa przed rozpoczęciem mutowalnej pożyczki, chociaż wymaga aktualizacji kompilatora i szkolenia zespołu.
Wybrane rozwiązanie i wynik: Wybrano rozwiązanie 3 po potwierdzeniu, że środowisko produkcyjne obsługuje Rust 1.31+. Kod został przekształcony w celu usunięcia sztucznego zagnieżdżenia, co pozwoliło, aby niemutowalna pożyczka zakończyła się natychmiast po walidacji i umożliwiło mutowalną naprawę w następnej linii. To zmniejszyło złożoność cyklomatyczną z 12 do 4 i wyeliminowało alokację pamięci na stercie o wielkości 2 MB na partię, spełniając surowe wymagania dotyczące opóźnienia.
Jak NLL współdziała z kolejnością usuwania tymczasowych wartości w złożonych wyrażeniach i dlaczego wymagało to zmian w regułach czasów życia dla tymczasowych wartości?
Wielu kandydatów zakłada, że NLL wpływa tylko na nazwane powiązania let. Jednak NLL wprowadził dokładną elaborację usuwania dla tymczasowych wartości na poziomie MIR. W wyrażeniach takich jak if let Some(x) = &mutex.lock().unwrap().data { ... }, tymczasowy MutexGuard musi pozostać żywy aż do użycia x, ale nie dłużej. Przed NLL żył do końca zdania, co potencjalnie mogło prowadzić do zakleszczeń. NLL wykorzystuje analizę przepływu danych do wstawienia flag usuwania, które niszczą tymczasowe wartości natychmiast po ich ostatnim użyciu, nawet w złożonym przepływie sterowania, zapewniając, że blokady są zwalniane na czas.
Dlaczego NLL wciąż odrzuca programy, w których mutowalna pożyczka jest tworzona po niemutowalnej pożyczce, nawet jeśli niemutowalna pożyczka nie jest już używana, gdy jest częścią zależności noszonej w pętli?
NLL przeprowadza analizę możliwego użycia na grafie przepływu sterowania, która jest wrażliwa na przepływ, ale nie na ścieżkę. Jeśli niemutowalna pożyczka jest tworzona wewnątrz pętli i używana w jednej iteracji, kolejna iteracja nie może utworzyć mutowalnej pożyczki, ponieważ CFG zakłada, że stara pożyczka może być dostępna. Kandydaci często oczekują, że NLL oceni konkretne warunki gałęzi (wrażliwość na ścieżkę). Jednak NLL zapewnia bezpieczeństwo dla wszystkich możliwych ścieżek wykonania, wymagając, aby pożyczka była definitywnie martwa w każdej ścieżce przed dopuszczeniem konfliktowej pożyczki. To zapobiega subtelnym błędom użycia po zwolnieniu w zależnościach noszonych w pętli, które byłyby niewidoczne w prostej analizie leksykalnej.
Jaka jest konkretna rola podwójnych pożyczek w ramach NLL i jak rozwiązują one konflikt "odbiorca metody vs. argumenty"?
NLL wprowadził podwójne pożyczki specjalnie w celu obsługi wzorców autorefowania wywołań metod, takich jak vec.push(vec.len()). Podczas ewaluacji kompilator rezerwuje mutowalną pożyczkę dla odbiorcy (vec) w stanie „zarezerwowanym”, kompatybilnym z niemutowalnymi pożyczkami podczas obliczania argumentów (vec.len()). Po ocenie argumentów pożyczka „aktywuje się” do pełnej mutowalności. Kandydaci często mylą to z ogólnym skracaniem czasów życia NLL lub ponownym pożyczaniem. Różnica jest kluczowa: podwójne pożyczki tymczasowo zawieszają ekskluzywność podczas oceny argumentów, co jest możliwe dzięki analizie CFG, która śledzi punkty rezerwacji i aktywacji osobno, co zachowuje ergonomię łańcuchów metod bez łamania reguł aliasingu.