В nightly-сборках Rust включили новую версию анализатора заимствований

Если коротко: в nightly-сборках Rust по умолчанию включают следующую версию анализатора заимствований — Polonius Alpha. В ближайшие месяцы разработчики планируют подготовить её к стабилизации.

Что меняется

У Rust появляется новая релиз анализатора заимствований. Первый анализатор, популярный как AST borrowck, имел множество ограничений. В 2019 году его заменили механизмом NLL — за исключением режима миграции, который использовался для более понятных сообщений об ошибках. Окончательно этот режим удалили в 2022 году.

Работа над Polonius началась в 2018 году как часть развития NLL. Первая реализация проходила набор тестов NLL и принимала корректный исходник, который NLL отклонял. Тем не менее её производительность оказалась неприемлемой.

В большинстве случаев тест заимствований работала медленнее NLL, а на некоторых программах время компиляции увеличивалось настолько, что практическое использование Polonius было невозможно. В последующие годы авторы пытались ускорить исходную модель, но устранить основные проблемы с производительностью не удалось.

В 2023 году команда предложила новый вариант анализатора в стиле Polonius. Он потребовал минимальных изменений в существующей реализации NLL и сохранил возможность в дальнейшем принимать больше корректных программ.

Изначально эту версию рассчитывали подготовить к стабилизации ещё в 2024 году, но работа затянулась в связи с других задач и технических сложностей.

Polonius Alpha включают в nightly-сборках

Сейчас команда не знает о нерешённых проблемах в той части Polonius, которую планируют стабилизировать под названием Polonius Alpha. Производительность равным образом считается в целом приемлемой для стабилизации, хотя отдельные детали разработчики ещё продолжают оценивать.

Следовательно Polonius Alpha включают в nightly-сборках Rust по умолчанию. До стабилизации, запланированной на конец 2026 года, команда рассчитывает выявить:

• серьёзные регрессии производительности;

• потенциально некорректное поведение анализатора;

• проблемы с диагностикой и сообщениями об ошибках.

На момент публикации авторы не обнаружили изменений в диагностике. Сообщать о проблемах можно через GitHub или Zulip.

Что умеет Polonius Alpha

Главное отличие Polonius Alpha от NLL — аналитика отношений между временами жизни с учётом конкретной ветки выполнения программы.

Минимальный пример кода, который принимает Polonius Alpha, но отклоняет текущий анализатор NLL:

fn reborrow(a: &mut u8) -> &mut u8 { let b = &mut *a; if true { b } else { a }
}

На практике чаще встречается похожая ситуация при работе с HashMap:

fn get_mut_or_default<'r, K: Hash + Eq + Copy, V: Default>( map: &'r mut HashMap<K, V>, key: K,
) -> &'r mut V { match map.get_mut(&key) { Some(value) => value, None => { map.insert(key, V::default()); map.get_mut(&key).unwrap() } }
}

В этом примере опция либо возвращает существующее значение из HashMap, либо добавляет значение по умолчанию и затем возвращает изменяемую ссылку на него. NLL полагает, что заимствование, созданное вызовом get_mut, может сохраняться и в ветке None, поэтому последующий вызов insert приводит к ошибке. Polonius Alpha анализирует ветки выполнения отдельно и понимает, что в ветке None предыдущее заимствование больше не используется.

Проблема в том, что ветка Some(value) => value заставляет анализатор заимствований считать, что ссылка, возвращаемая из map.get_mut(&key), существует на протяжении всей функции из-за возвращаемого типа &'r mut V. Одновременно в ветке None это заимствование уже не используется.

Текущий анализатор NLL не учитывает такие различия между ветками выполнения: его анализ не зависит от потока выполнения программы. Polonius Alpha решает эту проблему благодаря анализа с учётом конкретных веток и понимает, что в ветке None исходное заимствование больше не активно.

Ограничения Polonius Alpha

Одновременно Polonius Alpha пока нельзя считать полностью завершённой заменой старой реализации Polonius. Некоторые программы, которые успешно компилировались с первоначальной медленной реализацией Polonius, всё ещё не проходят проверку с Polonius Alpha.

В частности:

struct X { next: Option<Box<X>> } fn conditional() { let mut b = Some(Box::new(X { next: None })); let mut p = &mut b; while let Some(now) = p { if true { p = &mut now.next; } }
}

Впрочем, авторы отмечают, что нашли и обратные случаи: есть программы, которые компилируются с Polonius Alpha, но не проходят проверку старой реализацией Polonius. Следовательно Polonius Alpha нельзя считать просто подмножеством предыдущей версии.

Эффективность

Сейчас Polonius Alpha выполняет как минимум тот же объём работы, что и NLL, а в некоторых случаях больше. Следовательно команда отдельно следит за возможными ухудшениями времени компиляции.

При проверке десяти тысяч самых популярных пакетов на crates.io авторы обнаружили относительно небольшое количество заметных регрессий. Даже в тех случаях, когда они проявляются, влияние обычно остаётся небольшим.

На графике каждая точка соответствует одному из 10 тысяч самых загружаемых пакетов на crates.io. Чёрная линия обозначает условный порог значимой регрессии: ухудшение времени компиляции на 1% с дополнительным масштабированием для проектов, которые собираются менее чем за 30 секунд. Красным отмечены пакеты, которые превысили этот порог.

По горизонтальной оси показано время компиляции пакета без зависимостей при использовании NLL. По вертикальной — отношение времени компиляции с Polonius Alpha к времени компиляции с NLL.

Для пяти наиболее проблемных пакетов из верхней части списка авторы отдельно анализируют причины замедления.

За пределами топ-10 тысяч пакетов команда в первую очередь проверяла проекты с большим количеством заимствований. Максимальная обнаруженная регрессия составила приблизительно 2–3 раза.

Разработчики уже начали разбирать причины этих замедлений и ищут способы их устранить. Одновременно они считают, что в общем и целом такие изменения производительности допустимы: подобные случаи редкие, а получаемые возможности Polonius Alpha существенно расширяют возможности проверки заимствований относительно NLL.

Как выключить Polonius Alpha

Polonius Alpha включён только в nightly-сборках Rust. Если нужно вернуться к стандартному анализатору NLL, его можно отключить через параметр -Zpolonius=off.

Например, напрямую при запуске rustc:

-Zpolonius=off

или через переменную окружения:

RUSTFLAGS=-Zpolonius=off

Также настройку можно добавить в файл .cargo/config.toml проекта:

[target.x86_64-unknown-linux-gnu]
rustflags = ["-Zpolonius=off"]

Разработчики предлагают сообщать в GitHub или Zulip о случаях, когда приходится отключать Polonius Alpha, и описывать причины такого решения.

Что дальше

В ближайшие месяцы команда Rust будет отслеживать сообщения об ошибках в GitHub и Zulip, исправлять известные проблемы с производительностью и готовить внутреннюю документацию по реализации.

После этого разработчики планируют стабилизировать Polonius Alpha до конца 2026 года.

Одновременно команда отмечает: хотя существуют программы, которые хотелось бы поддержать в будущем, но которые пока не компилируются ни с Polonius Alpha, ни с NLL, активное развитие новых возможностей Polonius после стабилизации этой версии пока не запланировано.

В дальнейшем работа будет главным образом сосредоточена на оптимизации и исправлении проблем с производительностью. К развитию новых возможностей Polonius команда может вернуться позже, но сейчас Polonius Alpha уже решает большинство наиболее частых проблем проверки заимствований, поэтому авторы переключают внимание на другие приоритетные задачи.

Разобраться, как Rust выглядит на фоне других современных платформ, можно 5 августа на бесплатном демо-уроке с практикующими экспертами — «Битва нативных платформ: Spring Boot 4, Quarkus, Micronaut, KMP, Go и Rust».

Цельный список бесплатных уроков августа смотрите в дайджесте.