Большинство статей про Rust заканчиваются на borrow checker и lifetimes, как будто внутри компилятора живёт только проверяльщик заимствований и злой шрифтовый дизайнер для сообщений об ошибках. На деле там целый зоопарк механизмов, о которых редко пишут даже на конференциях. Я собрал несколько по настоящему любопытных вещей, которые меняют представление о том, как устроен язык изнутри, и подкрепил каждый сюжет кодом, который можно скопировать и проверить самому.
Начнём с того, чего никто не ждёт. Знакомая всем конструкция Option ссылки занимает ровно столько же байт, сколько и обычная ссылка. Это кажется магией: ведь у Option должен быть тег, отличающий Some от None. Никакого тега нет. Компилятор знает, что ссылка в Rust никогда не может быть нулевой, и использует нулевой адрес как представление варианта None. Этот трюк называется niche optimization, и он работает гораздо шире, чем принято думать. Проверим руками:
use std::mem::size_of;
use std::num::NonZeroU8;
fn main() {
assert_eq!(size_of::<&u32>(), size_of::<Option<&u32>>());
assert_eq!(size_of::<NonZeroU8>(), 1);
assert_eq!(size_of::<Option<NonZeroU8>>(), 1);
// niche ищется рекурсивно по всей структуре типа
assert_eq!(size_of::<Result<Option<&u32>, ()>>(), size_of::<&u32>());
}}Тип NonZeroU8 имеет диапазон от 1 до 255, значит ноль это niche, и Option<NonZeroU8> снова влезает в один байт. Самое интересное начинается, когда вы вкладываете Option в Option или заворачиваете всё в Result. У bool niche это значения от 2 до 255, у char это диапазоны невалидных кодпоинтов Unicode, и компилятор честно их использует. Если хочется посмотреть глазами, как это устроено, помогает флаг -Zprint-type-sizes на nightly: он печатает раскладку каждого варианта enum с указанием, какие байты являются дискриминантом, а какие пошли в дело как niche.
Следующая малоизвестная история про drop. Все знают, что деструкторы в Rust детерминированы и вызываются при выходе из области видимости. Но что происходит, если переменная была частично перемещена? Компилятор должен помнить во время выполнения, какие поля ещё живы, а какие уже отданы. Раньше для этого существовали так называемые drop flags, скрытые булевы переменные рядом со значением. Сейчас drop flags вынесены в отдельный неявный кусок стекового фрейма и не влияют на размер ваших структур. Вот код, показывающий частичное перемещение в явном виде:
struct Big { name: String, payload: Vec<u8> }
fn main() {
let b = Big { name: "x".into(), payload: vec![0u8; 1024] };
let _moved = b.name; // поле name перемещено
// b.payload ещё живо, компилятор дропнет только его
drop(b.payload);
} // здесь ничего не дропается, drop flag сказал всё уже перемещено}Полностью статически определить судьбу значения нельзя, потому что путь исполнения может зависеть от рантайма, поэтому компилятор честно генерирует битовую маску инициализированности и проверяет её перед каждым потенциальным дропом. Если вам кажется, что это медленно, вы правы, но LLVM почти всегда выкидывает эти проверки на этапе оптимизации, видя, что путь до drop линеен.
Отдельного разговора заслуживает MIR, среднее представление компилятора. Между HIR и LLVM IR живёт собственный промежуточный язык Rust, придуманный специально для borrow checker. До его появления проверка заимствований работала на уровне AST и буквально захлёбывалась в сложных потоках управления, отсюда печально известная история с NLL, non-lexical lifetimes. Когда borrow checker переехал на MIR, многие случаи, которые раньше требовали искусственно укорачивать область жизни ссылки, заработали сами собой. Вот простой пример, который до NLL не компилировался, а сейчас идёт без звука:
fn main() {
let mut v = vec![1, 2, 3];
let first = &v[0];
println!("{}", first); // после этой строки first больше не нужен
v.push(4); // раньше это было ошибкой, сейчас всё хорошо
}}это не только про заимствования. На нём же выполняется const evaluation, тот самый интерпретатор, который считает значения констант на этапе компиляции. Внутри это полноценная виртуальная машина с моделью памяти, проверкой UB и собственным аллокатором. Именно поэтому можно писать вещи вроде таких:
const fn fib(n: u32) -> u64 {
let (mut a, mut b) = (0u64, 1u64);
let mut i = 0;
while i < n { let t = a + b; a = b; b = t; i += 1; }
a
}
const FIB30: u64 = fib(30); // вычисляется в компиляторе, в бинарник попадает уже 832040}Если вы пишете const fn, а потом удивляетесь, почему какие то операции не работают в const контексте, ответ обычно лежит здесь: интерпретатор просто не реализует конкретную примитивную операцию, а не язык запрещает её философски.
Теперь про модель памяти, о которой почти не говорят. У Rust пока нет официально зафиксированной модели памяти, но де факто используется Stacked Borrows, а сейчас идёт переход на Tree Borrows. Это не та же модель, что в C++. Идея в том, что у каждой ссылки есть тег, и при создании новой ссылки тег пушится в стек разрешений, привязанный к участку памяти. Когда вы используете старую ссылку поверх новой, компилятор виртуально проверяет, что её тег ещё лежит в стеке. Если нет, это undefined behavior, даже если по C-шным правилам алиасинга всё было бы законно. Именно это позволяет Rust агрессивно помечать ссылки как noalias на уровне LLVM, чем не может похвастаться даже restrict в C. Вот пример кода, который выглядит невинно, но является UB по Stacked Borrows, и Miri его ловит:
fn main() {
let mut x = 42;
let r1 = &mut x;
let raw = r1 as *mut i32;
let r2 = &mut *r1; // перезаимствуем, сверху ложится новый тег
*r2 = 7;
unsafe { *raw = 13; } // raw был создан раньше r2 и был сброшен со стека
println!("{}", x); // Miri: Undefined Behavior
}}Пару лет назад из за этого пришлось временно отключить noalias в LLVM, потому что в самом LLVM находились баги, которые проявлялись только на коде из rustc. Запустить свою программу под Miri и увидеть, как он находит нарушение Stacked Borrows в библиотеке, которой пять лет, отдельный сорт удовольствия.
Ещё одна неочевидная деталь касается мономорфизации. Когда вы пишете дженерик функцию, компилятор создаёт по копии для каждой комбинации типов, и это известно. Менее известно то, что Rust борется с раздуванием бинарника через так называемое polymorphization, экспериментальный проход, который замечает, что параметр типа на самом деле не используется в теле функции, и склеивает мономорфизации обратно в одну. Параллельно работает share-generics, который позволяет крейтам переиспользовать инстанциации друг друга.
И напоследок про async. async fn в Rust это не что то магическое: компилятор берёт тело функции и превращает его в стейт машину, конкретно в анонимный enum, где каждый вариант это точка приостановки между await. Локальные переменные, живущие через await, становятся полями этого enum. Попробуйте запустить вот это и удивитесь размеру:
use std::mem::size_of_val;
async fn small() { /* пустая футура */ }
async fn big() {
let buf = [0u8; 1024]; // лежит на стеке async блока
small().await; // буфер живёт через await
println!("{}", buf.len());
}
fn main() {
let f = big();
println!("{}", size_of_val(&f)); // > 1024 байт
}}}Если вам кажется, что быть Box<dyn Future> всегда лёгким, это из за такого рода явлений он внезапно становится очень жирным. Компилятор пытается переиспользовать слоты под локальные переменные, чьи времена жизни не пересекаются, через generator layout optimization, но эта оптимизация работает не всегда хорошо, и долгое время являлась причиной мемов про async футуры размером с многоквартирный дом. Поэтому std::mem::size_of_val на результате async блока хороший способ найти неожиданно раздутые футуры до того, как они доедут до прода.
Rust внутри устроен как набор очень практичных компромиссов между выразительностью и тем, что можно реально доказать на этапе компиляции. Когда смотришь на язык со стороны niche optimization, drop flags, MIR и Stacked Borrows, становится понятно, что borrow checker это лишь верхушка айсберга, и именно невидимая часть отвечает за то, что Rust остаётся быстрым и предсказуемым там, где другие языки давно ушли бы в рантайм.
Пишу про Rust в тг, если интересно залетайте, готовлю вторую часть статьи!
Спасибо за внимание!