Лабораторна робота № 5. Набір програм, що не компілюються (borrow checker)

Модель володіння і правила запозичень викладені на лекції 5 того самого тижня; часи життя — у СРС 09 і на лекції 6. Розділ нижче наведено як довідку до діагностичної роботи, а не як первинне викладення матеріалу.

Модель володіння (ownership) — набір статичних правил Rust, які компілятор перевіряє під час компіляції, без затримки виконання й без збирача сміття: кожне значення має рівно одного власника; коли значення передається у функцію за значенням (не через посилання), відбувається переміщення (move) — попередня змінна втрачає право доступу до значення. Спроба використати змінну після переміщення дає помилку компіляції E0382 ("use of moved value") — не попередження, а жорстку відмову збирати програму.

Borrow checker — та частина rustc, що перевіряє правила запозичень: у будь-який момент часу для одного значення може існувати або довільна кількість незмінних посилань (&T), або рівно одне змінне (&mut T), і жодне з них не може пережити дані, на які вказує. Порушення дає помилки з кодами на кшталт E0502 (конфлікт незмінного й змінного запозичення в одній області видимості) чи E0499 (кілька змінних запозичень одночасно).

Мінімальне виправлення E0382 зазвичай не потребує .clone(). Найчастіша причина хибного переміщення — допоміжна функція приймає значення за володінням (String), хоча насправді лише читає його вміст і могла б приймати запозичення (&str):

// Проблема: process(log) переміщує log, друга спроба використання — помилка
fn process(s: String) -> String { s.to_uppercase() }

// Виправлення: process лише позичає — log лишається дійсним після виклику
fn process(s: &str) -> String { s.to_uppercase() }

Це змінює контракт лише внутрішньої допоміжної функції, не чіпаючи публічну сигнатуру й логіку алгоритму — саме такого мінімалізму вимагає діагностична робота з чужим (чи "мертвим") кодом.

Час життя (lifetime) — параметр типу посилання, що описує, наскільки довго воно лишається дійсним; потрібен лише на рівні 2 цієї роботи. У переважній більшості випадків компілятор виводить часи життя автоматично за правилами lifetime elision. Але коли функція повертає посилання, походження якого залежить від того, яке саме з кількох вхідних посилань проживе довше — компілятор вимагає явної анотації в сигнатурі (помилка E0106, missing lifetime specifier):

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() >= y.len() { x } else { y }
}

Явний час життя не змінює фактичний час життя значення в пам'яті й не подовжує його — він лише повідомляє компілятору зв'язок між часами життя різних посилань (тут: результат живе не довше за менше з двох вхідних 'a), щоб той міг статично довести безпеку коду.

Типова стратегія діагностики:

1. Прочитати повідомлення компілятора повністю, звернувши увагу на рядок і стовпець, куди вказує ^^^, і на службові нотатки (note:), які сучасний rustc часто додає з підказкою напряму виправлення.
2. Визначити, яке саме значення "втрачено" (moved) чи яке запозичення конфліктує.
3. Отримати розгорнуте пояснення командою rustc --explain <код> (наприклад, rustc --explain E0382).
4. Знайти мінімальну зміну: запозичення замість переміщення, звуження області видимості блоком { }, зміна порядку операцій або явна анотація часу життя — не переписування логіки з нуля.

Надлишкове копіювання (.clone() "про всяк випадок") часто працює, компілюється й навіть проходить тести — але ціною зайвих виділень пам'яті й копіювань даних на кожному кроці обробки. Рефакторинг після відновлення роботоздатності коду замінює такі місця на роботу через посилання (&T, ітератори .iter()), коли повне володіння копією насправді не потрібне.