Времена жизни — бесплатный тест онлайн

Вопрос 1 из 25

Как исправить участок с `String::from` без обхода проверки компилятора?

/// ```compile_fail
/// fn bad() -> &'static str {
///     let s = String::from("x");
///     &s
/// }
/// ```
pub fn lifetime_example() {}

Вызвать `drop` для одной из привязок перед `compile_fail`, не пересматривая, кто должен владеть ресурсом после операции. Проверять lifetime-API сочетанием положительных примеров и compile-fail сценариев; runtime-тест не способен выполнить код, который должен быть отвергнут borrow checker. Добавить время жизни `'static` к ссылкам вокруг `compile_fail`, не меняя фактический срок существования владельца. Ресурс тогда живёт дольше исходной операции и освобождается уже вне её естественной границы. Клонировать задействованное значение перед `compile_fail` и не менять отношения владения; лишнюю копию считать приемлемой ценой простого кода. Приписать возвращаемой ссылке время жизни static; одной аннотации достаточно, чтобы данные жили дольше. Ресурс тогда живёт дольше исходной операции и освобождается уже вне её естественной границы.

Вопрос 2 из 25

Что должно войти в отрицательный тест механизма «Сокращение времён жизни»?

Elision не анализирует тело функции и не угадывает, какой из нескольких аргументов возвращается; неоднозначная сигнатура всё равно требует аннотации. Два индекса массива можно считать разными без проверки, если в тестовых данных они различались. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Если обычный пример работает, вложенный match или замыкание не способны изменить способ перемещения значения. Тогда поведение «Сокращение времён жизни» при раннем выходе выводили бы из обычного пути. Добавление static к параметру устраняет все случаи висячих ссылок, включая ссылки на локальные переменные. В результате «Сокращение времён жизни» считали бы безопасным и на путях, которых пример не выполняет. Для ссылок достаточно проверить непустой ввод; время жизни владельца не является отдельной границей контракта.

Вопрос 3 из 25

Как лучше всего описать гарантию механизма «Статические ссылки»?

Аннотация времени жизни продлевает существование владельца до конца функции. Следовательно, поведение `same` считалось бы одинаковым для всех допустимых типов. Drop вызывается сборщиком мусора в неопределённый момент после последнего использования значения. Контракт «Статические ссылки» считался бы одинаковым при любом состоянии входа. Последнее использование ссылки всегда совпадает с концом лексического блока. В результате «Статические ссылки» считали бы безопасным и на путях, которых пример не выполняет. Lifetime-аннотация управляет временем хранения данных и может продлить жизнь локального владельца. &'static T означает ссылку, допустимую до конца программы; это не то же самое, что значение T: 'static, которое может просто не содержать краткоживущих ссылок.

Вопрос 4 из 25

Что показывает `choose` применительно к механизму «Сокращение времён жизни»?

fn choose(x: &str, y: &str) -> &str { x }

Код не компилируется из-за неоднозначного источника выходной ссылки, хотя тело фактически возвращает x. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Положительный тест уже подтверждает все соседние состояния, поэтому отдельная матрица входов не требуется. Тогда различия между обычным и граничным случаем для `choose` исчезли бы. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Отсутствие сообщения инструмента означает, что опасная ветвь была выполнена и признана корректной.

Вопрос 5 из 25

Какой сценарий нельзя выводить из одного положительного примера «Связь входа и выхода»?

Порядок уничтожения локальных значений одинаков во всех ситуациях, включая поля структуры и временные выражения. Два индекса массива можно считать разными без проверки, если в тестовых данных они различались. Проверку ошибки для «Связь входа и выхода» при таком подходе заменили бы успешным примером. Добавление static к параметру устраняет все случаи висячих ссылок, включая ссылки на локальные переменные. Из этого следовало бы, что иной порядок операций для «Связь входа и выхода» ничего не меняет. Для ссылок достаточно проверить непустой ввод; время жизни владельца не является отдельной границей контракта. Следовательно, для «Связь входа и выхода» не понадобилось бы явное предусловие. Слишком сильная связь всех аргументов одним lifetime искусственно сокращает результат и может отвергнуть безопасный вызов без изменения тела.

Вопрос 6 из 25

Какое утверждение о «Связь входа и выхода» остаётся верным при смене входных данных?

Неизменяемая ссылка сохраняет право на чтение даже во время активного изменяемого заимствования. Контракт «Связь входа и выхода» считался бы одинаковым при любом состоянии входа. Нелексические времена жизни позволяют ссылке пережить уничтожение владельца, когда после блока она используется только для чтения. Тогда различия между обычным и граничным случаем для «Связь входа и выхода» исчезли бы. Аннотация времени жизни продлевает существование владельца до конца функции. Контракт «Связь входа и выхода» считался бы одинаковым при любом состоянии входа. Корректная сигнатура выражает множество возможных источников возвращаемой ссылки, и вызывающий код полагается именно на эту связь. Lifetime-аннотация управляет временем хранения данных и может продлить жизнь локального владельца. Проверку ошибки для «Связь входа и выхода» при таком подходе заменили бы успешным примером.

Вопрос 7 из 25

Какой способ правки делает использование `head` корректным и явным?

fn head(text: &str) -> &str { &text[..1] }

Клонировать задействованное значение перед `head` и не менять отношения владения; лишнюю копию считать приемлемой ценой простого кода. Оставлять elision в простых сигнатурах с однозначной связью; добавлять имена, когда несколько входных ссылок делают источник результата неясным. Приписать возвращаемой ссылке время жизни static; одной аннотации достаточно, чтобы данные жили дольше. Поэтому ошибочный сценарий вокруг `head` не проверяли бы отдельно. Добавить время жизни `'static` к ссылкам вокруг `head`, не меняя фактический срок существования владельца. Вызвать `drop` для одной из привязок перед `head`, не пересматривая, кто должен владеть ресурсом после операции.

Вопрос 8 из 25

Какие значения останутся доступными после `longer`?

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

Сигнатура обещает, что возвращаемая ссылка живёт не дольше пересечения времён жизни x и y; функция не продлевает ни одну строку. Сборка пройдёт, поскольку неизменяемая ссылка сохраняет право на чтение даже во время активного изменяемого заимствования. Контракт `longer` считался бы одинаковым при любом состоянии входа. Rust примет этот код, поскольку последнее использование ссылки всегда совпадает с концом лексического блока. Компилятор отвергнет фрагмент, поскольку любая передача по ссылке требует времени жизни static. Проверка типов пропустит этот путь: аннотация времени жизни продлевает существование владельца до конца функции.

Вопрос 9 из 25

Что именно подтверждает проверка с `String::from`?

let outer = String::from("long");
let result;
{
    let inner = String::from("x");
    result = longer(&outer, &inner);
    println!("{result}");
}

Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Отсутствие сообщения инструмента означает, что опасная ветвь была выполнена и признана корректной. Дополнительный сценарий вокруг `String::from` при таком толковании уже не требуется. Успешного основного сценария достаточно; отмену, частичное завершение и повторный вход отдельно проверять не нужно. Использование внутри блока допустимо; вынести result за время жизни inner нельзя, потому что функция могла вернуть ссылку на inner. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Дополнительный сценарий вокруг `String::from` при таком толковании уже не требуется. Поэтому ошибочный сценарий вокруг `String::from` не проверяли бы отдельно.

Вопрос 10 из 25

Какой вывод допустим после запуска `String::from` и чего он не доказывает?

let long = String::from("long");
let r;
{
    let hint = String::from("hint");
    r = first(&long, &hint);
}
assert_eq!(r, "long");

Если основной путь стабилен, ранний выход и повторный вход можно не воспроизводить отдельно. Такое рассуждение переносило бы вывод о `String::from` на неисполненную ветвь. Раз тест прошёл, производительность решения тоже можно считать подтверждённой. Успешный запуск подтверждает корректность не только этого пути, но и остальных ветвей программы. Тест компилируется и подтверждает, что результат не зависит от времени жизни hint. Результат можно считать доказательством свойства языка, даже если он зависит от конкретной библиотеки или платформы.

Вопрос 11 из 25

Что система типов не проверит самостоятельно для механизма «Тестирование и инструменты Cargo»?

Сравнение точного текста borrow-checker ошибки хрупко между версиями компилятора; достаточно закрепить факт отказа и смысл сценария. Добавление static к параметру устраняет все случаи висячих ссылок, включая ссылки на локальные переменные. Такое рассуждение переносило бы вывод о «Тестирование и инструменты Cargo» на неисполненную ветвь. Для ссылок достаточно проверить непустой ввод; время жизни владельца не является отдельной границей контракта. По этой логике отдельная проверка «Тестирование и инструменты Cargo» на другом входе считалась бы лишней. Утечка через Rc или mem::forget невозможна в безопасном Rust, поэтому поведение Drop проверять не нужно. После успешной компиляции можно не проверять изменение порядка вызовов: borrow checker уже рассмотрел все будущие сценарии.

Вопрос 12 из 25

Какое правило Rust точнее всего описывает механизм «Тестирование и инструменты Cargo»?

Аннотация времени жизни продлевает существование владельца до конца функции. Из этого следовало бы, что иной порядок операций для «Тестирование и инструменты Cargo» ничего не меняет. Lifetime-аннотация управляет временем хранения данных и может продлить жизнь локального владельца. В результате «Тестирование и инструменты Cargo» считали бы безопасным и на путях, которых пример не выполняет. Неизменяемая ссылка сохраняет право на чтение даже во время активного изменяемого заимствования. В результате «Тестирование и инструменты Cargo» считали бы безопасным и на путях, которых пример не выполняет. Компиляционные гарантии времён жизни тестируют на стадии сборки, а не попыткой вызвать неопределённое поведение во время выполнения. Нелексические времена жизни позволяют ссылке пережить уничтожение владельца, когда после блока она используется только для чтения. Тогда различия между обычным и граничным случаем для «Тестирование и инструменты Cargo» исчезли бы.

Вопрос 13 из 25

Что ещё нужно проверить, прежде чем считать реализацию «Статические ссылки» надёжной?

Добавление static к параметру устраняет все случаи висячих ссылок, включая ссылки на локальные переменные. Контракт «Статические ссылки» считался бы одинаковым при любом состоянии входа. Утечка Box::leak способна создать static-ссылку во время выполнения, но память тогда намеренно не освобождается и это должно быть частью архитектурного решения. Утечка через Rc или mem::forget невозможна в безопасном Rust, поэтому поведение Drop проверять не нужно. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Для ссылок достаточно проверить непустой ввод; время жизни владельца не является отдельной границей контракта. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Два индекса массива можно считать разными без проверки, если в тестовых данных они различались. Тогда различия между обычным и граничным случаем для «Статические ссылки» исчезли бы.

Вопрос 14 из 25

Как устранить причину диагностики в строке с `longer`?

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

Связывать lifetime-параметром только ссылки, между которыми действительно существует зависимость; не ставить один и тот же lifetime на все аргументы механически. Вызвать `drop` для одной из привязок перед `longer`, не пересматривая, кто должен владеть ресурсом после операции. Добавить время жизни `'static` к ссылкам вокруг `longer`, не меняя фактический срок существования владельца. Ресурс тогда живёт дольше исходной операции и освобождается уже вне её естественной границы. Приписать возвращаемой ссылке время жизни static; одной аннотации достаточно, чтобы данные жили дольше. Ресурс тогда живёт дольше исходной операции и освобождается уже вне её естественной границы. Из этого следовало бы, что иной порядок операций для `longer` ничего не меняет. Клонировать задействованное значение перед `longer` и не менять отношения владения; лишнюю копию считать приемлемой ценой простого кода.

Вопрос 15 из 25

Каким будет результат последней строки этого фрагмента?

let literal: &'static str = "built into binary";
fn same(x: &'static str) -> &'static str { x }
println!("{}", same(literal));

Код компилируется, но порядок освобождения выбирается сборщиком мусора во время выполнения. Код компилируется, но нарушение владения обнаруживается паникой уже после начала выполнения. Код компилируется: строковый литерал имеет данные, доступные всё время работы программы, и может быть &'static str. Проверка типов завершится ошибкой: заимствование прекращается только после явного вызова drop для ссылки. Такое рассуждение переносило бы вывод о `same` на неисполненную ветвь. Этот фрагмент будет отклонён: деструктор вызывается до выполнения последней строки области.

Вопрос 16 из 25

Какой путь выполнения выберет Rust после `first`?

fn first<'a>(primary: &'a str, _hint: &str) -> &'a str { primary }

До запуска дело не дойдёт: любая передача по ссылке требует времени жизни static. До выполнения код дойдёт без ошибки компиляции, поскольку неизменяемая ссылка сохраняет право на чтение даже во время активного изменяемого заимствования. Код не пройдёт проверку: заимствование прекращается только после явного вызова drop для ссылки. Возвращаемая ссылка связана только с primary; краткое время жизни hint не ограничивает результат. Сборка пройдёт, поскольку аннотация времени жизни продлевает существование владельца до конца функции.

Вопрос 17 из 25

Что проверяет `Box::leak`, если не расширять вывод за пределы выполненного пути?

let leaked: &'static str = Box::leak(String::from("cached").into_boxed_str());
assert_eq!(leaked, "cached");

Проверка показывает создание static-ссылки через намеренную утечку; Drop для этой строки не будет вызван. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Раз тест прошёл, производительность решения тоже можно считать подтверждённой. Отсутствие сообщения инструмента означает, что опасная ветвь была выполнена и признана корректной.

Вопрос 18 из 25

Какой путь выполнения выберет Rust после `head`?

fn head(text: &str) -> &str { &text[..1] }

До выполнения код дойдёт без ошибки компиляции, поскольку аннотация времени жизни продлевает существование владельца до конца функции. Код не пройдёт проверку: любая передача по ссылке требует времени жизни static. Сигнатура допустима без явных аннотаций: единственное входное время жизни присваивается выходной ссылке по правилам elision. Проверка типов завершится ошибкой: заимствование прекращается только после явного вызова drop для ссылки. Код пройдёт проверку компилятора: компилятор автоматически копирует значение при повторном использовании имени.

Вопрос 19 из 25

Что Rust гарантирует при корректном использовании «Сокращение времён жизни»?

Нелексические времена жизни позволяют ссылке пережить уничтожение владельца, когда после блока она используется только для чтения. Тогда поведение «Сокращение времён жизни» при раннем выходе выводили бы из обычного пути. Аннотация времени жизни продлевает существование владельца до конца функции. Следовательно, для «Сокращение времён жизни» не понадобилось бы явное предусловие. Lifetime-аннотация управляет временем хранения данных и может продлить жизнь локального владельца. Такое рассуждение переносило бы вывод о «Сокращение времён жизни» на неисполненную ветвь. Несколько &mut допустимы, когда программист знает, что адреса различаются; отдельный безопасный интерфейс для доказательства не нужен. Такое рассуждение переносило бы вывод о «Сокращение времён жизни» на неисполненную ветвь. Правила lifetime elision автоматически назначают отдельные времена входным ссылкам и связывают выход с единственным входом либо с &self в методе.

Вопрос 20 из 25

На какое правило следует опираться при ревью кода по теме «Аннотации»?

Нелексические времена жизни позволяют ссылке пережить уничтожение владельца, когда после блока она используется только для чтения. Последнее использование ссылки всегда совпадает с концом лексического блока. Следовательно, поведение `longer` считалось бы одинаковым для всех допустимых типов. Аннотации lifetime описывают отношения между ссылками, которые компилятор должен проверить; они не изменяют фактические области жизни значений. Аннотация времени жизни продлевает существование владельца до конца функции. Следовательно, для «Аннотации» не понадобилось бы явное предусловие. Неизменяемая ссылка сохраняет право на чтение даже во время активного изменяемого заимствования. Из этого следовало бы, что иной порядок операций для «Аннотации» ничего не меняет.

Вопрос 21 из 25

Какое изменение решает проблему в месте применения `first`?

fn first<'a>(primary: &'a str, _hint: &str) -> &'a str { primary }

Назвать lifetime только у входа, из которого может происходить результат; параметры, не связанные с выходом, оставить с отдельным неявным временем. Вызвать `drop` для одной из привязок перед `first`, не пересматривая, кто должен владеть ресурсом после операции. Клонировать задействованное значение перед `first` и не менять отношения владения; лишнюю копию считать приемлемой ценой простого кода. Приписать возвращаемой ссылке время жизни static; одной аннотации достаточно, чтобы данные жили дольше. Из этого следовало бы, что иной порядок операций для `first` ничего не меняет. Добавить время жизни `'static` к ссылкам вокруг `first`, не меняя фактический срок существования владельца.

Вопрос 22 из 25

Как следует интерпретировать результат проверки `String::from`?

/// ```compile_fail
/// fn bad() -> &'static str {
///     let s = String::from("x");
///     &s
/// }
/// ```
pub fn lifetime_example() {}

Компилятор отвергнет фрагмент, поскольку любая передача по ссылке требует времени жизни static. Из этого следовало бы, что иной порядок операций для `bad` ничего не меняет. До выполнения код дойдёт без ошибки компиляции, поскольку аннотация времени жизни продлевает существование владельца до конца функции. Поэтому ошибочный сценарий вокруг `bad` не проверяли бы отдельно. compile_fail doctest фиксирует запрет возврата ссылки на локальные данные и будет проверен cargo test --doc. Код компилируется, но порядок освобождения выбирается сборщиком мусора во время выполнения. Тогда поведение `bad` при раннем выходе выводили бы из обычного пути. Компилятор отвергнет фрагмент, поскольку деструктор вызывается до выполнения последней строки области.

Вопрос 23 из 25

Какую регрессию должен ловить `String::from`?

/// ```compile_fail
/// fn bad() -> &'static str {
///     let s = String::from("x");
///     &s
/// }
/// ```
pub fn lifetime_example() {}

# cargo test --doc
# RUSTDOCFLAGS="-D warnings" cargo test --doc

Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Дополнительный сценарий вокруг `String::from` при таком толковании уже не требуется. В результате `bad` считали бы безопасным и на путях, которых пример не выполняет. Вторая команда дополнительно превращает предупреждения rustdoc в ошибки и помогает не пропустить устаревшие примеры и ссылки. Совпадение полного текста диагностики является главным и стабильным контрактом этой проверки. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Одного успешного примера достаточно, чтобы считать проверенными и невыполненные ветви контракта.

Вопрос 24 из 25

Какой эксплуатационный край отличает контракт «Аннотации» от удачного примера?

Одинаковое имя lifetime не требует, чтобы аргументы жили одинаково долго; при вызове выбирается подходящее общее более короткое время. Различие между Copy и Clone влияет только на скорость, но не на доступность исходного имени. Тогда поведение «Аннотации» при раннем выходе выводили бы из обычного пути. Порядок уничтожения локальных значений одинаков во всех ситуациях, включая поля структуры и временные выражения. Добавление static к параметру устраняет все случаи висячих ссылок, включая ссылки на локальные переменные. Контракт «Аннотации» считался бы одинаковым при любом состоянии входа. Для ссылок достаточно проверить непустой ввод; время жизни владельца не является отдельной границей контракта.

Вопрос 25 из 25

Какая правка выдержит ревью контракта «Статические ссылки»?

let literal: &'static str = "built into binary";
fn same(x: &'static str) -> &'static str { x }
println!("{}", same(literal));

Добавить время жизни `'static` к ссылкам вокруг `literal`, не меняя фактический срок существования владельца. Не требовать &'static в API только ради удобства хранения; часто правильнее параметр lifetime, owned String или Arc<str>, отражающий реальный срок владения. Приписать возвращаемой ссылке время жизни static; одной аннотации достаточно, чтобы данные жили дольше. Ресурс тогда живёт дольше исходной операции и освобождается уже вне её естественной границы. Тогда различия между обычным и граничным случаем для `same` исчезли бы. Клонировать задействованное значение перед `literal` и не менять отношения владения; лишнюю копию считать приемлемой ценой простого кода. Вызвать `drop` для одной из привязок перед `literal`, не пересматривая, кто должен владеть ресурсом после операции.