Вопросы по Rust

Расскажите о механизме «полного заимствования» (total borrowing) в контексте правил работы с &mut. Почему следующий код не компилируется, и как это связано с правилом «no alias»?

let mut x = 42;

let a = & mut x;
let b = & x; // ошибка

println!("{}", *a);

Ошибка возникает на строке let b = &x;, хотя a дальше не используется до println!. Компилятор Rust руководствуется правилом «no alias» (нет алиасинга для мутабельных ссылок): пока существует активная &mut T, никакие другие ссылки на это значение не допускаются, даже только для чтения.

Здесь вступает в силу механизм нелексического, NLL(Non-Lexical Lifetimes) заимствования. Компилятор анализирует liveness ссылки a. В текущем коде a живет до последнего использования в println!. Следовательно, на момент создания b ссылка a все еще считается "живой", что нарушает правило. Если бы мы убрали println! или перенесли его после использования b, ситуация могла бы измениться. NLL позволяет сокращать время жизни до последнего использования, но здесь println! держит a живым.

Как в Rust устроен механизм «дроп-проверки» (drop check) и почему наличие деструктора у типа влияет на время жизни ссылок? Приведите пример, когда тип с пользовательским Drop заставляет компилятор считать ссылки живыми дольше, чем обычно

Механизм: Обычно время жизни ссылок проверяется на основе их использования (liveness). Однако если у типа есть кастомный деструктор impl Drop, компилятор выполняет drop check — он предполагает, что деструктор может обратиться к полям структуры. Поэтому ссылки внутри структуры должны жить дольше или столько же, сколько и сама структура, вплоть до момента реального падения (drop).

struct MyStruct<'a> {
    data: &'a i32,
}

impl<'a> Drop for MyStruct<'a> {
    fn drop(&mut self) {
        println!("{}", self.data); // деструктор использует ссылку
    }
}

fn main() {
    let x = 10;
    let s;
    {
        let y = 20;
        s = MyStruct { data: &y };
    } // y уничтожается здесь, но s еще жив
    // Ошибка компиляции: `y` does not live long enough
}

Если убрать impl Drop, код скомпилируется при условии, что s не используется, потому что ссылка &y нигде не используется после смерти y. Но наличие Drop заставляет компилятор продлить требование времени жизни до момента вызова деструктора s (в конце main), а y уже мертв.

В чем разница между Pin<Box<T>>, Box<Pin<T>> и Pin<&mut T>? Когда вы обязаны использовать Pin не только для async/Future? Приведите пример самоссылающейся структуры.

Pin<Box<T>> — владеющий умный указатель, который гарантирует, что значение T никогда не будет перемещено в памяти ( если T: !Unpin). Сама коробка (Box) может перемещаться, но память, на которую она указывает, зафиксирована. Стандартный способ создания: Box::pin(value).

Box<Pin<T>> - коробка, внутри которой лежит уже закрепленное значение Pin<T>. Это странный и редко используемый кейс, потому что Pin<T> сам по себе не имеет смысла без указателя. Обычно так не делают.

Pin<&mut T> - закрепленная ссылка на чужые данные. Она не владеет памятью, а только гарантирует, что данные не будут перемещены через эту ссылку. Используется в Future::poll().

Когда обязателен Pin? Для самоссылающихся структур, например, состояние стрима или генератора. Если вы вручную создаете структуру, где одно поле хранит указатель на другое поле, без Pin перемещение структуры сломает этот указатель.

use std::pin::Pin;
use std::marker::PhantomPinned;

struct SelfReferential {
    data: String,
    ptr: *const String,
    _pin: PhantomPinned,
}

impl SelfReferential {
    fn new(data: String) -> Self {
        SelfReferential {
            data,
            ptr: std::ptr::null(),
            _pin: PhantomPinned,
        }
    }

    fn init(self: Pin<&mut Self>) {
        let this = unsafe { self.get_unchecked_mut() };
        this.ptr = &this.data as *const String;
    }
}

Объясните, как работают impl Trait в позиции аргумента (входной параметр) и в позиции возврата. Почему fn foo(x: impl Debug) и fn bar<T: Debug>(x: T) — это не полные аналоги, особенно с точки зрения системы типов и мономорфизации?

Аргумент: fn foo(x: impl Debug) — это анонимный универсальный параметр. Это синтаксический сахар для fn foo<T: Debug>(x: T). Полные аналоги с точки зрения семантики типов — да, но есть нюансы:

Внутри функции x имеет однозначный конкретный тип, но вы не можете назвать его имя.

Основное отличие: нельзя использовать impl Trait для указания типа поля в структуре или для явной аннотации type вне функции. Возврат: fn foo() -> impl Debug — это экзистенциальный тип (существует некоторый тип, реализующий Debug). Здесь никакой мономорфизации "на стороне вызывающего" нет. Компилятор знает конкретный возвращаемый тип внутри функции, но для внешнего мира это неименованный конкретный тип. Главное отличие от fn bar<T: Debug>() -> T: в bar вызывающий сам выбирает T, а в foo возвращаемый тип фиксирован реализацией функции. Это позволяет возвращать замыкания или итераторы, не создавая Box.

Что такое «субтипирование времени жизни» и как оно связано с дисперсией (variance) в Rust? Объясните, почему &'static T можно передать туда, где ожидают &'a T, но обратное не работает. Как дисперсия влияет на Cell<T> и RefCell<T>?

Субтипирование: 'static — подтип 'a, потому что статическое время жизни "длиннее" любого 'a. Поэтому &'static T можно передать туда, где ожидают &'a T (ковариантность).

Дисперсия определяет, как меняется отношение подтипов для составных типов:

Ковариантность (&'a T по 'a): если 'static <: 'a, то &'static T <: &'a T (можно сужать время жизни). Инвариантность для типов с внутренней мутабельностью (Cell<T>, RefCell<T>). Компилятор делает их инвариантными по T, чтобы избежать проблем с безопасностью. Если бы Cell<T> был ковариантным, можно было бы "обмануть" проверку заимствования, сохраняя ссылку на короткоживущие данные в ячейку, которая живет дольше.

Когда использование std::mem::replace и std::mem::take предпочтительнее, чем std::mem::swap для работы с Option<T> в цикле? Как это связано с паттерном «take and mutate» и предотвращением двойного заимствования?

Использование mem::take (или mem::replace с Default) позволяет извлечь значение из Option, оставив на его месте None, за одно действие и без лишних проверок.

Паттерн "take and mutate":

let mut opt = Some(vec![1, 2, 3]);
let inner = opt.take(); // opt становится None, inner = Some(vec)
if let Some( mut v) = inner {
v.push(4);
opt = Some(v);
}

Это позволяет избежать двойного заимствования (&mut нельзя получить дважды) и делает код идиоматичным для изменения содержания Option без лишних match.

swap требует иметь второе значение для обмена, что менее удобно, когда вам нужно просто "вынуть и положить новое". take короче и выразительнее, так как использует Default (для Option это None).

Почему код let x: fn() -> i32 = || 42; не компилируется? В чем фундаментальное отличие замыканий от указателей на функции, и как это проявляется в размере типов (size_of)? Что такое захват по значению, по ссылке и по уникальной ссылке?

let x: fn () -> i32 = | | 42; // Ошибка!

Ошибка: замыкание — это анонимный тип структуры, который захватывает переменные из окружения (даже если ничего не захватывает). Указатель fn() -> i32 — это указатель на свободную функцию (без состояния). Они несовместимы. Можно привести только замыкание, не захватывающее окружение (move без переменных), к fn, но явно:

let x: fn () -> i32 = ( | | 42) as fn () -> i32; // работает

Размеры:

• fn() -> i32 имеет размер 8 байт (указатель).
• Замыкание || 42 без захвата имеет размер 0 байт (Zero-Sized Type, ZST).
• Замыкание с захватом по значению move || x имеет размер, равный размеру захваченных переменных.

Захват: компилятор генерирует структуру с полями. По ссылке &T, по уникальной ссылке &mut T или по значению T — это определяет, как именно замыкание владеет данными.

Как работают пользовательские аллокаторы в Rust (начиная с #[global_allocator])? В каких случаях Vec<T> или Box<T> НЕ используют глобальный аллокатор, и как создать тип, который жестко привязан к конкретному аллокатору (например, Arena)?

Начиная с Rust 1.68+ (и стабилизации allocator_api), можно использовать #[global_allocator] для переопределения глобального аллокатора (например, на Jemalloc или собственный).

Когда Vec НЕ использует глобальный аллокатор?

• Когда используется с параметром аллокатора: Vec<T, A: Allocator>. Например, Vec::new_in(allocator) создает вектор, использующий конкретный экземпляр аллокатора.
• Типы в alloc крейте (например, Vec, Box) по умолчанию параметризованы аллокатором, но для удобства есть алиас Vec<T\> = Vec<T, Global>.

use std::alloc::Allocator;
struct MyArena;
unsafe impl Allocator for MyArena { /* ... */ }

let arena = MyArena;
let mut vec: Vec<i32, & MyArena> = Vec::new_in( & arena);

Здесь vec жестко привязан к arena через время жизни и не будет использовать глобальный аллокатор.

Объясните механизм «codegen unit» и «incremental compilation». Как разделение на крейты влияет на возможности оптимизаций (LTO, мономорфизация)? Почему в release-профиле иногда выгоднее выключать инлайн для некоторых функций?

• Codegen units (CGU) — это количество независимых единиц компиляции, на которое разбивается крейт. Больше CGU = быстрее компиляция (параллелизм), но меньше оптимизаций, так как межпроцедурные оптимизации (MIR inlining) ограничены пределами одного CGU. Incremental compilation сохраняет промежуточные результаты (HIR/MIR) между запусками, перекомпилируя только измененные CGU. Влияние крейтов: Мономорфизация (генерация кода для обобщенных функций) происходит внутри каждого крейта. Без LTO ( Link Time Optimization) код из разных крейтов не инлайнится и не оптимизируется вместе. LTO включает анализ на уровне линковки, но замедляет сборку.

• Почему выключают инлайн в release? - Инлайн увеличивает размер бинарника (code bloat) и может ухудшить локальность кеша. Иногда большие функции инлайнятся там, где это невыгодно (например, в холодных путях). Контроль через атрибуты #[inline(never)] или настройки панибратского инлайна в Cargo.toml помогает найти баланс между скоростью и размером.

Что такое «autoref» (автоматическое взятие ссылки) в контексте вызова методов через .?

Почему следующий код работает, хотя x — это значение, а не ссылка? И в каком случае это приводит к неочевидной ошибке с трейтами, реализованными для &T vs T?

let x = String::from("hello");
x.len(); // как это работает, если len принимает &self?

Почему x.len() работает, если len принимает &self?

Компилятор Rust при вызове метода через . автоматически вставляет взятие ссылки (&, &mut или \*) столько раз, сколько нужно, чтобы удовлетворить сигнатуру метода. Это называется autoref (или автоматическая референция/дереференция).

Для x: String, метод len(&self) ожидает &String. Компилятор неявно преобразует x в &x.

Где это приводит к неочевидной ошибке? Если у вас есть два трейта: один реализован для T, другой — для &T, и они оба имеют метод с одним именем. Автореф может выбрать не ту реализацию.

Классический пример с Iterator vs IntoIterator

let v = vec![1, 2, 3];
for x in & v { ... } // работает, потому что &Vec реализует IntoIterator
for x in v { ... }

Но если вы напишете:

fn take_iter<T: Iterator>(it: T) {}
take_iter(v.iter()); // Ok
take_iter( & v); // Ошибка: &Vec не реализует Iterator, но реализует IntoIterator

Здесь автореф мешает, если ожидается именно Iterator.

Еще пример с трейтом Deref: автореф и автоматическое разыменование могут привести к тому, что вызывается метод у &T, а не у T, если они оба определены, что иногда сбивает с толку.