Макросы — бесплатный тест онлайн

Вопрос 1 из 25

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

Путь crate внутри экспортированного макроса всегда означает crate пользователя. Следовательно, поведение `add_one!` считалось бы одинаковым для всех допустимых типов. $crate разрешается к crate, где макрос вызван, а не где определён. Имена, введённые макросом, захватывают одноимённые локальные переменные вызывающего кода. Гигиена макросов разделяет имена, введённые определением, и имена из места вызова, предотвращая многие случайные захваты. Гигиена означает, что макрос не может обращаться к именам из места вызова даже через параметры.

Вопрос 2 из 25

Какой дефект способен воспроизвести тест `choose!`?

macro_rules! choose { ($e:expr) => { "expr" }; ($i:ident) => { "ident" }; }
assert_eq!(choose!(name), "expr");

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

Вопрос 3 из 25

Какой вывод о механизме «Фрагменты» соответствует модели Rust?

Фрагмент в macro_rules парсится по выбранной синтаксической категории, а не как произвольная строка токенов; после захвата его повторное сопоставление ограничено. Macro_rules выбирает наиболее специфичную ветвь независимо от порядка объявления. Такое рассуждение переносило бы вывод о «Фрагменты» на неисполненную ветвь. Macro_rules проверяет типы аргументов до выбора подходящей ветви. В результате «Фрагменты» считали бы безопасным и на путях, которых пример не выполняет. $crate разрешается к crate, где макрос вызван, а не где определён. Следовательно, поведение `make_fn!` считалось бы одинаковым для всех допустимых типов. Фрагмент ident принимает любое выражение, если оно вычисляется в имя. Тогда различия между обычным и граничным случаем для «Фрагменты» исчезли бы.

Вопрос 4 из 25

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

Doctest не компилирует макросы и проверяет только отображение документации. Следовательно, поведение `macro_lib::vec_of_strings` считалось бы одинаковым для всех допустимых типов. Derive-макрос изменяет исходное объявление структуры на месте, удаляя или переставляя поля. Тогда различия между обычным и граничным случаем для «Тестирование и инструменты Cargo» исчезли бы. Путь crate внутри экспортированного макроса всегда означает crate пользователя. Unit-тест внутри crate не всегда обнаруживает проблемы с экспортом и путями $crate; интеграционный или doctest вызывает макрос как настоящий пользователь. $crate разрешается к crate, где макрос вызван, а не где определён. Следовательно, поведение `macro_lib::vec_of_strings` считалось бы одинаковым для всех допустимых типов.

Вопрос 5 из 25

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

Макрос, проверенный внутри собственного crate, обязательно доступен тем же путём внешнему пользователю. Если раскрытие выглядит правильно в cargo expand, типовые и поведенческие тесты излишни. Переименование зависимости пользователя не влияет на абсолютные пути, зашитые в макрос. Изменение порядка правил не способно поменять результат для пересекающихся шаблонов. Порядок правил важен: более общий шаблон, стоящий первым, может перехватить ввод и сделать узкую ветвь недостижимой.

Вопрос 6 из 25

Какой результат даст этот фрагмент с `#[derive(MySerialize)]`?

#[derive(MySerialize)]
struct User { id: u64, name: String }

Код компилируется, но procedural macro загружается как плагин уже запущенного бинарного файла. Значит, выполнение должно пройти через `#[derive(MySerialize)]` без изменения сигнатуры. Компиляция закончится диагностикой: tokenStream возвращается во время компиляции. До последней строки и наблюдаемого результата программа при таком разборе не доходит. Derive-процедурный макрос получает токены объявления User и генерирует дополнительные item, обычно impl, но не изменяет тело структуры на этапе выполнения. Компилятор отвергнет фрагмент, поскольку derive создаёт дополнительный impl. До последней строки и наблюдаемого результата программа при таком разборе не доходит. Проверка типов завершится ошибкой: доктест вызывает экспортированный макрос снаружи crate. До последней строки и наблюдаемого результата программа при таком разборе не доходит.

Вопрос 7 из 25

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

/// ```
/// use macro_lib::vec_of_strings;
/// let v = vec_of_strings![1, 2];
/// assert_eq!(v, ["1", "2"]);
/// ```
/// ```compile_fail
/// let _ = macro_lib::vec_of_strings![let x = 1];
/// ```
pub fn macro_docs() {}

# cargo test --doc
# cargo test --test exported_macros

Успешный запуск подтверждает корректность не только этого пути, но и остальных ветвей программы. Такое рассуждение переносило бы вывод о `macro_docs` на неисполненную ветвь. Отсутствие сообщения инструмента означает, что опасная ветвь была выполнена и признана корректной. Успешного основного сценария достаточно; отмену, частичное завершение и повторный вход отдельно проверять не нужно. Тогда различия между обычным и граничным случаем для `macro_docs` исчезли бы. Успешная сборка примера уже подтверждает контракт, поэтому результат выполнения можно не фиксировать. Проверку ошибки для `macro_docs` при таком подходе заменили бы успешным примером. Первая команда проверяет примеры документации, вторая — импорт и раскрытие экспортируемых макросов из внешней точки зрения.

Вопрос 8 из 25

Что должно войти в отрицательный тест механизма «Гигиена»?

Гигиена не исправляет логические конфликты публичных путей и импортов; для обращения к собственному crate из экспортируемого макроса используют $crate. Если раскрытие выглядит правильно в cargo expand, типовые и поведенческие тесты излишни. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Макрос, проверенный внутри собственного crate, обязательно доступен тем же путём внешнему пользователю. Переименование зависимости пользователя не влияет на абсолютные пути, зашитые в макрос. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Изменение порядка правил не способно поменять результат для пересекающихся шаблонов.

Вопрос 9 из 25

Какую гарантию даёт `make_fn!`, а какую нужно проверять отдельно?

make_fn!(answer, { let x = 21; x * 2 });
assert_eq!(answer(), 42);

Успешная ветвь служит достаточным доказательством поведения при ошибке и повторном выполнении. В результате `make_fn!` считали бы безопасным и на путях, которых пример не выполняет. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Блочное выражение подходит под expr и сохраняет локальные привязки внутри сгенерированной функции. Отсутствие сообщения инструмента означает, что опасная ветвь была выполнена и признана корректной. Дополнительный сценарий вокруг `make_fn!` при таком толковании уже не требуется. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно.

Вопрос 10 из 25

Какой вывод о механизме «Декларативные макросы macro_rules» соответствует модели Rust?

macro_rules сопоставляет последовательность токенов с шаблонами и раскрывает подходящую ветвь до проверки типов сгенерированного кода. Macro_rules выбирает наиболее специфичную ветвь независимо от порядка объявления. По этой логике отдельная проверка «Декларативные макросы macro_rules» на другом входе считалась бы лишней. Фрагмент ident принимает любое выражение, если оно вычисляется в имя. Порядок правил не влияет на выбор, потому что компилятор ищет самый специфичный шаблон. Следовательно, для «Декларативные макросы macro_rules» не понадобилось бы явное предусловие. Macro_rules проверяет типы аргументов до выбора подходящей ветви. Тогда поведение «Декларативные макросы macro_rules» при раннем выходе выводили бы из обычного пути.

Вопрос 11 из 25

Какая часть механизма «Процедурные макросы» зафиксирована тестом `#[derive(MySerialize)]`?

#[derive(MySerialize)]
struct User { id: u64, name: String }

# cargo expand (внешний инструмент) показывает раскрытый код;
# cargo test проверяет его компиляцию и поведение.

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

Вопрос 12 из 25

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

Ошибки spans не влияют на пригодность публичного procedural macro. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Если раскрытие выглядит правильно в cargo expand, типовые и поведенческие тесты излишни. compile_fail подтверждает отказ, но не гарантирует качество сообщения; для диагностик процедурного макроса полезны отдельные UI-тесты по ключевым span и смыслу. Новые синтаксические формы редакции языка всегда автоматически совпадают со старыми fragment specifiers одинаково. Макрос, проверенный внутри собственного crate, обязательно доступен тем же путём внешнему пользователю. Такое рассуждение переносило бы вывод о «Тестирование и инструменты Cargo» на неисполненную ветвь.

Вопрос 13 из 25

Как Rust выполнит этот фрагмент о механизме «Гигиена»?

macro_rules! add_one {
    ($x:expr) => {{ let temp = $x; temp + 1 }};
}
let temp = 100;
let result = add_one!(temp);

Код компилируется, но гигиена имён проверяется только отладчиком после раскрытия. Значит, выполнение должно пройти через `add_one!` без изменения сигнатуры. Код компилируется и result равен 101: локальный temp внутри раскрытия не захватывает одноимённую привязку вызывающего кода. До выполнения код дойдёт без ошибки компиляции, поскольку macro_rules проверяет типы аргументов до выбора подходящей ветви. Компиляция завершится успешно: путь crate внутри экспортированного макроса всегда означает crate пользователя. Фрагмент успешно соберётся: имена, введённые макросом, захватывают одноимённые локальные переменные вызывающего кода.

Вопрос 14 из 25

Как обновить фрагмент с `add_one!`, чтобы ошибка исчезла по существу?

macro_rules! add_one {
    ($x:expr) => {{ let temp = $x; temp + 1 }};
}
let temp = 100;
let result = add_one!(temp);

Использовать локальные имена внутри отдельного блока и передавать внешние значения метапеременными; не рассчитывать на неявный доступ к локальным именам места вызова. Вводить фиксированные локальные имена и рассчитывать на захват переменных вызывающего кода. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Считать один модульный тест внутри crate достаточным для проверки экспорта и путей пользователя. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Зашить абсолютный путь к crate и данные этого фрагмента, не учитывая переименование зависимости у пользователя. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Ограничиться снимком раскрытия макроса и не компилировать его через внешний путь использования. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым.

Вопрос 15 из 25

На какую часть контракта распространяется проверка `crate::helper`?

#[macro_export]
macro_rules! call_helper { () => { $crate::helper() }; }

$crate разрешается к crate, где макрос определён, поэтому переименование зависимости у пользователя не ломает внутренний путь. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Отсутствие сообщения инструмента означает, что опасная ветвь была выполнена и признана корректной. Успешного основного сценария достаточно; отмену, частичное завершение и повторный вход отдельно проверять не нужно. Тогда различия между обычным и граничным случаем для `crate::helper` исчезли бы. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же.

Вопрос 16 из 25

Что исправляет не симптом, а саму ошибку вокруг `macro_lib::vec_of_strings`?

/// ```
/// use macro_lib::vec_of_strings;
/// let v = vec_of_strings![1, 2];
/// assert_eq!(v, ["1", "2"]);
/// ```
/// ```compile_fail
/// let _ = macro_lib::vec_of_strings![let x = 1];
/// ```
pub fn macro_docs() {}

Разбирать вход `macro_lib::vec_of_strings` как строку и собирать выход конкатенацией, не сохраняя токены, spans и гигиену. Игнорировать spans и формировать все ошибки на имени самого макроса, а не на проблемном токене. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Считать один модульный тест внутри crate достаточным для проверки экспорта и путей пользователя. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Следовательно, для `macro_docs` не понадобилось бы явное предусловие. Ограничиться снимком раскрытия макроса и не компилировать его через внешний путь использования. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. В результате `macro_docs` считали бы безопасным и на путях, которых пример не выполняет. Для макроса тестировать каждую ветвь, пустой ввод, завершающие разделители, ошибки синтаксиса, гигиену и использование из внешнего crate.

Вопрос 17 из 25

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

macro_rules! vec_of_strings {
    ($($x:expr),* $(,)?) => { vec![$($x.to_string()),*] };
}
let v = vec_of_strings![1, "two",];

Сборка остановится: макрос принимает завершающую запятую. До последней строки и наблюдаемого результата программа при таком разборе не доходит. Макрос принимает ноль или больше выражений с необязательной завершающей запятой и создаёт Vec<String> для разных типов с to_string. Код компилируется, но неподходящая ветвь макроса вызывает panic при первом вызове. Значит, выполнение должно пройти через `to_string` без изменения сигнатуры. Сборка пройдёт, поскольку macro_rules проверяет типы аргументов до выбора подходящей ветви. Код компилируется и даёт ожидаемый результат: порядок правил не влияет на выбор, а компилятор ищет самый специфичный шаблон.

Вопрос 18 из 25

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

Сгенерированный публичный API не участвует в semver, потому что отсутствует в исходном тексте. Изменения грамматики edition могут влиять на набор выражений для некоторых specifier; публичный макрос нужно тестировать в поддерживаемых editions. Макрос, проверенный внутри собственного crate, обязательно доступен тем же путём внешнему пользователю. Тогда различия между обычным и граничным случаем для «Фрагменты» исчезли бы. Новые синтаксические формы редакции языка всегда автоматически совпадают со старыми fragment specifiers одинаково. Поэтому ошибочный сценарий вокруг «Фрагменты» не проверяли бы отдельно. Переименование зависимости пользователя не влияет на абсолютные пути, зашитые в макрос.

Вопрос 19 из 25

Что нужно пересмотреть в использовании `#[derive(MySerialize)]`, чтобы код стал корректным?

#[derive(MySerialize)]
struct User { id: u64, name: String }

Разбирать вход `derive` как строку и собирать выход конкатенацией, не сохраняя токены, spans и гигиену. Использовать обычный путь crate:: во внешнем макросе вместо $crate. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Хранить изменяемое глобальное состояние в procedural macro, полагаясь на последовательный порядок вызовов сборки. Держать procedural macro crate небольшим, выдавать span-привязанные ошибки и генерировать обычный проверяемый Rust-код с минимальной магией. Проверять procedural macro только снимком cargo expand без компиляции результата. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым.

Вопрос 20 из 25

Какое изменение входа способно поменять вывод о механизме «Процедурные макросы»?

Если раскрытие выглядит правильно в cargo expand, типовые и поведенческие тесты излишни. Тогда различия между обычным и граничным случаем для «Процедурные макросы» исчезли бы. Новые синтаксические формы редакции языка всегда автоматически совпадают со старыми fragment specifiers одинаково. В результате «Процедурные макросы» считали бы безопасным и на путях, которых пример не выполняет. Ошибки spans не влияют на пригодность публичного procedural macro. Макрос запускается с полномочиями процесса сборки, поэтому зависимость procedural macro относится к цепочке поставки и требует аудита как исполняемый build-код. Макрос, проверенный внутри собственного crate, обязательно доступен тем же путём внешнему пользователю. Тогда поведение «Процедурные макросы» при раннем выходе выводили бы из обычного пути.

Вопрос 21 из 25

Как изменить фрагмент с `to_string`, не перенося ошибку на время выполнения?

macro_rules! vec_of_strings {
    ($($x:expr),* $(,)?) => { vec![$($x.to_string()),*] };
}
let v = vec_of_strings![1, "two",];

Поставить самый общий шаблон первым и рассчитывать, что компилятор позже выберет более специфичный. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Разбирать вход `macro_rules` как строку и собирать выход конкатенацией, не сохраняя токены, spans и гигиену. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Заменить все фрагменты на tt и собирать синтаксис строковыми операциями внутри раскрытия. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Ограничиться снимком раскрытия макроса и не компилировать его через внешний путь использования. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Поэтому ошибочный сценарий вокруг `to_string` не проверяли бы отдельно. Ограничивать синтаксис макроса ясными шаблонами и делегировать вычисление обычным функциям, где это возможно; поддерживать завершающую запятую для эргономики.

Вопрос 22 из 25

Какое ограничение языка определяет поведение «Процедурные макросы»?

Derive-макрос изменяет исходное объявление структуры на месте, удаляя или переставляя поля. Следовательно, для «Процедурные макросы» не понадобилось бы явное предусловие. $crate разрешается к crate, где макрос вызван, а не где определён. Проверку ошибки для «Процедурные макросы» при таком подходе заменили бы успешным примером. Процедурный макрос выполняется во время работы программы и может читать её состояние. Следовательно, поведение `#[derive(MySerialize)]` считалось бы одинаковым для всех допустимых типов. Процедурные макросы выполняются компилятором во время сборки, принимают TokenStream и возвращают TokenStream; derive, attribute и function-like формы имеют разные точки применения. Процедурный макрос выполняется при каждом запуске программы. Следовательно, для «Процедурные макросы» не понадобилось бы явное предусловие.

Вопрос 23 из 25

Какую гарантию даёт `macro_lib::vec_of_strings`, а какую нужно проверять отдельно?

/// ```
/// use macro_lib::vec_of_strings;
/// let v = vec_of_strings![1, 2];
/// assert_eq!(v, ["1", "2"]);
/// ```
/// ```compile_fail
/// let _ = macro_lib::vec_of_strings![let x = 1];
/// ```
pub fn macro_docs() {}

Код не пройдёт проверку: доктест вызывает экспортированный макрос снаружи crate. Код компилируется, но неподходящая ветвь макроса вызывает panic при первом вызове. Значит, выполнение должно пройти через `macro_lib::vec_of_strings` без изменения сигнатуры. Документация проверяет успешный внешний вызов и отдельный недопустимый синтаксис; оба сценария запускаются rustdoc через cargo test. Фрагмент успешно соберётся: путь crate внутри экспортированного макроса всегда означает crate пользователя. Компилятор примет фрагмент: macro_rules проверяет типы аргументов до выбора подходящей ветви.

Вопрос 24 из 25

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

macro_rules! make_fn {
    ($name:ident, $body:expr) => { fn $name() -> i32 { $body } };
}
make_fn!(answer, 40 + 2);

Зашить абсолютный путь к crate и данные этого фрагмента, не учитывая переименование зависимости у пользователя. Вводить фиксированные локальные имена и рассчитывать на захват переменных вызывающего кода. Заменить все фрагменты на tt и собирать синтаксис строковыми операциями внутри раскрытия. Выбирать наиболее точный fragment specifier: ident, expr, ty, pat, item и другие задают грамматику и улучшают диагностику. Разбирать вход `macro_rules` как строку и собирать выход конкатенацией, не сохраняя токены, spans и гигиену.

Вопрос 25 из 25

Каков конечный результат операции `make_fn!`?

macro_rules! make_fn {
    ($name:ident, $body:expr) => { fn $name() -> i32 { $body } };
}
make_fn!(answer, 40 + 2);

До запуска дело не дойдёт: доктест вызывает экспортированный макрос снаружи crate. Проверка типов пропустит этот путь: macro_rules проверяет типы аргументов до выбора подходящей ветви. Проверка типов завершится ошибкой: макрос принимает завершающую запятую. Фрагмент успешно соберётся: фрагмент ident принимает любое выражение, если оно вычисляется в имя. Фрагмент ident принимает имя функции, а expr — выражение тела; сгенерированная answer возвращает 42.