Коллекции и строки — бесплатный тест онлайн

Вопрос 1 из 20

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

let mut keys: Vec<_> = counts.keys().copied().collect();
keys.sort_unstable();
assert_eq!(keys, vec!["a", "b"]);

Совпадение полного текста диагностики является главным и стабильным контрактом этой проверки. Сортировка превращает неопределённый порядок обхода HashMap в устойчивый результат теста. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Дополнительный сценарий вокруг `keys` при таком толковании уже не требуется. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Нормальный результат на одном входе позволяет распространить тот же вывод на отмену и частичное выполнение. Тогда поведение `keys` при раннем выходе выводили бы из обычного пути.

Вопрос 2 из 20

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

Порядок обхода HashMap является частью стабильного публичного контракта стандартной библиотеки. Entry создаёт независимую копию значения и не даёт изменяемую ссылку внутрь карты. Порядок обхода HashMap стабилен внутри одной версии программы. HashMap::entry объединяет проверку наличия и доступ к слоту, избегая повторного поиска и конфликтующих заимствований. Vec гарантирует неизменность адреса элементов после выдачи ссылки на один из них. Из этого следовало бы, что иной порядок операций для «Словари HashMap» ничего не меняет.

Вопрос 3 из 20

Какое свойство «Индексация Unicode» сохранится после небольшого рефакторинга?

Длина String измеряется количеством символов, а не числом байтов UTF-8. Следовательно, поведение `String::from` считалось бы одинаковым для всех допустимых типов. String можно индексировать по номеру Unicode-символа тем же синтаксисом, что и массив байтов. Тогда различия между обычным и граничным случаем для «Индексация Unicode» исчезли бы. String хранит UTF-8 и не реализует индексирование одиночным числом, потому что индекс не может однозначно означать байт, символ или графему с постоянной стоимостью. Срез строки по любому целому индексу автоматически округляется до границы UTF-8. Поэтому ошибочный сценарий вокруг «Индексация Unicode» не проверяли бы отдельно. String индексируется по Unicode-символам за постоянное время. Тогда поведение «Индексация Unicode» при раннем выходе выводили бы из обычного пути.

Вопрос 4 из 20

На какой операции нарушается проверяемый Rust контракт?

let mut v = vec![1, 2, 3];
let first = &v[0];
v.push(4);
println!("{first}");

Код не компилируется: push может перераспределить буфер, поэтому активная ссылка на элемент конфликтует с изменяемым заимствованием вектора. Компилятор примет фрагмент: у Vec заранее указана ёмкость. Значит, выполнение должно пройти через `push` без изменения сигнатуры. Такая запись допустима, так как capacity является частью логического содержимого Vec и изменяет результат сравнения. Код компилируется, а проблема проявляется только при выполнении: push меняет только длину и никогда не затрагивает адрес элементов. Код считается допустимым, потому что vec сохраняет адрес буфера при любом push, потому что ссылка на элемент уже была выдана.

Вопрос 5 из 20

Какая правка выдержит ревью контракта «String и str»?

fn greet(name: &str) -> String { format!("Hello, {name}") }
let owned = String::from("Ferris");
let msg = greet(&owned);
println!("{msg}");

Принимать &str для чтения текста из String и строковых литералов; возвращать String, когда результат создаётся внутри и должен жить независимо. Собирать промежуточную коллекцию на каждом шаге `greet`, даже если задача допускает заимствование или ленивый проход. Использовать числовой индекс как индекс элемента независимо от представления данные этого фрагмента и способа хранения данных. Преобразовать все строки в Vec<char> независимо от профиля операций и расхода памяти. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Клонировать всю коллекцию перед `greet`, не отделяя требуемый элемент, срез или заимствованный просмотр.

Вопрос 6 из 20

Что система типов не проверит самостоятельно для механизма «Векторы Vec»?

Даже если текущей ёмкости фактически хватает, безопасный API push имеет общий контракт и компилятор не доказывает отсутствие перераспределения по runtime capacity. Уменьшение длины Vec автоматически уменьшает capacity и освобождает буфер. Такое рассуждение переносило бы вывод о «Векторы Vec» на неисполненную ветвь. Пустой Vec не имеет указателя, поэтому его нельзя передавать как ptr+len даже при len=0. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. После reserve ссылка на элемент остаётся допустимой для неограниченного числа push. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Удаление элемента HashMap не влияет на ранее сохранённые ссылки на другие элементы. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются.

Вопрос 7 из 20

Какая правка выдержит ревью контракта «Индексация Unicode»?

let text = String::from("Здравствуйте");
// let first = text[0];
println!("{}", text.chars().count());

Клонировать всю коллекцию перед `text`, не отделяя требуемый элемент, срез или заимствованный просмотр. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Индексировать String по байтовому номеру и считать, что один символ всегда занимает один байт. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Собирать промежуточную коллекцию на каждом шаге `text`, даже если задача допускает заимствование или ленивый проход. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Выбирать bytes() для байтов, chars() для Unicode scalar values и специализированную библиотеку для графем; срезы по индексам делать только по проверенным границам UTF-8. Использовать числовой индекс как индекс элемента независимо от представления данные этого фрагмента и способа хранения данных. В результате `chars` считали бы безопасным и на путях, которых пример не выполняет.

Вопрос 8 из 20

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

let text = "é";
assert_eq!(text.len(), 2);
assert_eq!(text.chars().count(), 1);

Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Один положительный сценарий покрывает контракт целиком, включая частичный результат и преждевременное завершение. Успешный запуск подтверждает корректность не только этого пути, но и остальных ветвей программы. Проверка различает длину UTF-8 в байтах и число Unicode scalar values; это не число графем для всех строк. Если код принят компилятором, отдельное наблюдение за результатом этого сценария избыточно.

Вопрос 9 из 20

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

fn greet(name: &str) -> String { format!("Hello, {name}") }
let owned = String::from("Ferris");
let msg = greet(&owned);
println!("{msg}");

Код компилируется, но выход за границы среза всегда возвращает пустой срез без panic. Значит, выполнение должно пройти через `String::from` без изменения сигнатуры. Компилятор примет фрагмент: string можно индексировать по номеру Unicode-символа тем же синтаксисом, что и массив байтов. Код компилируется: &String коэрцируется в &str, функция читает текст без получения владения, а возвращаемая строка принадлежит вызывающему коду. Код компилируется, но индексация строки возвращает ближайший Unicode-символ или заменяющий знак. Значит, выполнение должно пройти через `String::from` без изменения сигнатуры. Код считается допустимым, потому что срез строки по любому целому индексу автоматически округляется до границы UTF-8.

Вопрос 10 из 20

Что произойдёт после операции `std::collections::HashMap`?

use std::collections::HashMap;
let mut counts = HashMap::new();
for word in ["a", "b", "a"] {
    *counts.entry(word).or_insert(0) += 1;
}
println!("{}", counts["a"]);

Код печатает 2: entry выполняет поиск один раз и предоставляет изменяемую ссылку на существующее или вставленное значение. Компиляция завершится успешно: порядок обхода HashMap стабилен внутри одной версии программы. Код пройдёт проверку компилятора: entry создаёт независимую копию значения и не даёт изменяемую ссылку внутрь карты. Код компилируется, но итерация HashMap сортирует ключи при первом обходе. Значит, выполнение должно пройти через `std::collections::HashMap` без изменения сигнатуры. Компилятор отвергнет фрагмент, поскольку ключ HashMap реализует Eq и Hash. До последней строки и наблюдаемого результата программа при таком разборе не доходит.

Вопрос 11 из 20

Какое ограничение языка определяет поведение «String и str»?

Срез строки по любому целому индексу автоматически округляется до границы UTF-8. Поэтому ошибочный сценарий вокруг «String и str» не проверяли бы отдельно. String владеет изменяемым UTF-8 буфером, а str — заимствованный строковый срез; &String часто автоматически приводится к &str. String можно индексировать по номеру Unicode-символа тем же синтаксисом, что и массив байтов. Длина String измеряется количеством символов, а не числом байтов UTF-8. Тогда поведение «String и str» при раннем выходе выводили бы из обычного пути. String индексируется по Unicode-символам за постоянное время. Тогда различия между обычным и граничным случаем для «String и str» исчезли бы.

Вопрос 12 из 20

Какой край контракта «Индексация Unicode» чаще всего остаётся незамеченным?

ASCII-пример подтверждает безопасность тех же байтовых индексов для любого UTF-8 текста. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Индекс, равный длине строки, всегда обозначает последний символ. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Chars().nth(n) имеет постоянную стоимость, как индексирование массива. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Один ожидаемый порядок ключей можно закрепить в тесте без предварительной сортировки. По этой логике отдельная проверка «Индексация Unicode» на другом входе считалась бы лишней. Диапазонный срез строки проверяет границы UTF-8 во время выполнения и паникует, если начало или конец попадает внутрь многобайтового символа.

Вопрос 13 из 20

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

use std::collections::HashMap;
let mut counts = HashMap::new();
for word in ["a", "b", "a"] {
    *counts.entry(word).or_insert(0) += 1;
}
println!("{}", counts["a"]);

Сохранить ссылку на элемент Vec и после каждого push восстанавливать её тем же индексом без повторного заимствования. Использовать entry для атомарного по отношению к одному &mut Map шаблона «получить или вставить»; не делать отдельные contains_key и get_mut без причины. Собирать промежуточную коллекцию на каждом шаге `std::collections::HashMap`, даже если задача допускает заимствование или ленивый проход. Клонировать всю коллекцию перед `std::collections::HashMap`, не отделяя требуемый элемент, срез или заимствованный просмотр. Закрепить ожидаемый порядок HashMap одним успешным тестовым запуском. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым.

Вопрос 14 из 20

Что Rust гарантирует при корректном использовании «Векторы Vec»?

Vec владеет непрерывным буфером, а операция, меняющая его, требует &mut Vec и не может пересекаться с активными ссылками на элементы. Capacity является частью логического содержимого Vec и изменяет результат сравнения. Проверку ошибки для «Векторы Vec» при таком подходе заменили бы успешным примером. Vec сохраняет адрес буфера при любом push, потому что ссылка на элемент уже была выдана. По этой логике отдельная проверка «Векторы Vec» на другом входе считалась бы лишней. Сравнение Vec учитывает capacity и адрес буфера наряду с элементами. Поэтому ошибочный сценарий вокруг «Векторы Vec» не проверяли бы отдельно. Порядок обхода HashMap является частью стабильного публичного контракта стандартной библиотеки. В результате «Векторы Vec» считали бы безопасным и на путях, которых пример не выполняет.

Вопрос 15 из 20

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

let mut v = vec![1, 2, 3];
let first = v[0];
v.push(4);
assert_eq!(first, 1);

Раз тест прошёл, производительность решения тоже можно считать подтверждённой. Отсутствие сообщения инструмента означает, что опасная ветвь была выполнена и признана корректной. Совпадение полного текста диагностики является главным и стабильным контрактом этой проверки. Копирование i32 отделяет first от буфера Vec, поэтому последующий push безопасен и не меняет сохранённое значение. Результат можно считать доказательством свойства языка, даже если он зависит от конкретной библиотеки или платформы.

Вопрос 16 из 20

Какое условие способно превратить рабочий пример «Словари HashMap» в ошибочный?

Один ожидаемый порядок ключей можно закрепить в тесте без предварительной сортировки. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. ASCII-пример подтверждает безопасность тех же байтовых индексов для любого UTF-8 текста. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Порядок обхода стандартного HashMap не является стабильным; тесты не должны сравнивать последовательность пар без сортировки или упорядоченной структуры. Chars().nth(n) имеет постоянную стоимость, как индексирование массива. Удаление элемента HashMap не влияет на ранее сохранённые ссылки на другие элементы. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Тогда поведение «Словари HashMap» при раннем выходе выводили бы из обычного пути.

Вопрос 17 из 20

Какой риск остаётся после успешной компиляции кода по теме «String и str»?

Индекс, равный длине строки, всегда обозначает последний символ. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Chars().nth(n) имеет постоянную стоимость, как индексирование массива. Возвращать &str на локально созданный String нельзя; заимствованный результат должен быть частью входа или статических данных. Уменьшение длины Vec автоматически уменьшает capacity и освобождает буфер. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. ASCII-пример подтверждает безопасность тех же байтовых индексов для любого UTF-8 текста.

Вопрос 18 из 20

Как правильно прочитать результат диагностического сценария `prefix`?

fn prefix(s: &str) -> &str { &s[..1] }
assert_eq!(prefix("Rust"), "R");

Функция возвращает срез входной строки; пример корректен для ASCII, но индекс 1 может не быть границей UTF-8 символа на другом вводе. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Если код принят компилятором, отдельное наблюдение за результатом этого сценария избыточно. Тогда различия между обычным и граничным случаем для `prefix` исчезли бы. Совпадение полного текста диагностики является главным и стабильным контрактом этой проверки.

Вопрос 19 из 20

Какую несовместимость обнаружит компилятор?

let text = String::from("Здравствуйте");
// let first = text[0];
println!("{}", text.chars().count());

Сборка пройдёт, поскольку срез строки по любому целому индексу автоматически округляется до границы UTF-8. Индексация text[0] не компилируется, а chars().count() считает Unicode scalar values, не байты и не пользовательские графемы. Код компилируется, а проблема проявляется только при выполнении: индексация строки возвращает ближайший Unicode-символ или заменяющий знак. Фрагмент успешно соберётся: string можно индексировать по номеру Unicode-символа тем же синтаксисом, что и массив байтов. Код компилируется, а проблема проявляется только при выполнении: выход за границы среза всегда возвращает пустой срез без panic.

Вопрос 20 из 20

Какая правка выдержит ревью контракта «Векторы Vec»?

let mut v = vec![1, 2, 3];
let first = &v[0];
v.push(4);
println!("{first}");

Сохранить ссылку на элемент Vec и после каждого push восстанавливать её тем же индексом без повторного заимствования. Следовательно, для `push` не понадобилось бы явное предусловие. Собирать промежуточную коллекцию на каждом шаге `vec`, даже если задача допускает заимствование или ленивый проход. Клонировать всю коллекцию перед `vec`, не отделяя требуемый элемент, срез или заимствованный просмотр. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Преобразовать все строки в Vec<char> независимо от профиля операций и расхода памяти. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. По этой логике отдельная проверка `push` на другом входе считалась бы лишней. Использовать first до push, сохранить копию элемента, либо перестроить порядок операций; резервирование ёмкости не является разрешением для borrow checker.