Cargo, features и workspace — бесплатный тест онлайн

Вопрос 1 из 30

Что исправить вокруг `cargo build --locked`, чтобы граничный вход обрабатывался безопасно?

# Cargo.lock зафиксирован в репозитории приложения.
# cargo build --locked

Включить все features по умолчанию; так любая комбинация пользователей будет заведомо поддержана. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Зашить абсолютный путь к данные этого фрагмента в каждом месте использования, не сохраняя прежние переэкспорты и публичные пути. Удалять Cargo.lock перед каждой сборкой, чтобы зависимости всегда были свежими. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Сделать все элементы вокруг `Cargo` публичными, чтобы не разбирать фактическую границу модуля и путь внешнего пользователя. Коммитить Cargo.lock для приложений и инструментов, использовать --locked/--frozen в CI и сохранять toolchain; для библиотек понимать, что пользователи разрешают свой граф.

Вопрос 2 из 30

Как следует интерпретировать результат проверки `cargo test --workspace`?

# Минимальная матрица:
cargo test --workspace
cargo test --workspace --all-features
cargo test --workspace --no-default-features
cargo doc --workspace --no-deps

Матрица проверяет разные feature-наборы и документацию, но no-default-features может требовать выборочных -p, если не каждый member поддерживает пустой набор. Код компилируется, но выбор feature можно менять для уже запущенного бинарного файла. Значит, выполнение должно пройти через `cargo test --workspace` без изменения сигнатуры. Фрагмент успешно соберётся: удаление Cargo.lock гарантирует воспроизводимый выбор самых новых совместимых версий. Код считается допустимым, потому что workspace объединяет пакеты в один crate и общее пространство имён. Код считается допустимым, потому что feature Cargo автоматически включается при наличии одноимённого модуля.

Вопрос 3 из 30

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

Обновление lock-файла не требует просмотра транзитивных изменений и контрольных сумм. Контракт «Воспроизводимость» считался бы одинаковым при любом состоянии входа. Цикл зависимостей между пакетами workspace допустим, когда функции не вызывают друг друга. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Опциональная зависимость не влияет на граф и время сборки, пока её API не вызывается. Сборка одной целевой платформы подтверждает корректность всех target-specific секций манифеста. Контракт «Воспроизводимость» считался бы одинаковым при любом состоянии входа. Одинаковый Cargo.lock не гарантирует побитово одинаковый бинарник на разных системах; абсолютные пути, timestamps и native dependencies требуют отдельного контроля.

Вопрос 4 из 30

Что именно подтверждает проверка с `cargo build --locked`?

# Cargo.lock зафиксирован в репозитории приложения.
# cargo build --locked

# cargo build --locked --offline

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

Вопрос 5 из 30

Как Rust выполнит этот фрагмент о механизме «Рабочие пространства workspace»?

[workspace]
members = ["crates/core", "crates/cli"]
resolver = "3"

[workspace.dependencies]
serde = "1"

Workspace объединяет пакеты и общие настройки; члены могут наследовать версию зависимости через workspace = true, сохраняя единое разрешение. Код считается допустимым, потому что удаление Cargo.lock гарантирует воспроизводимый выбор самых новых совместимых версий. Код не пройдёт проверку: зависимость указана через workspace.dependencies. До последней строки и наблюдаемого результата программа при таком разборе не доходит. Такая запись допустима, так как workspace объединяет пакеты в один crate и общее пространство имён. Компилятор примет фрагмент: feature Cargo автоматически включается при наличии одноимённого модуля.

Вопрос 6 из 30

Какое свойство «Рабочие пространства workspace» сохранится после небольшого рефакторинга?

Workspace превращает пакеты в единый crate с одной библиотечной границей. Из этого следовало бы, что иной порядок операций для «Рабочие пространства workspace» ничего не меняет. Workspace совместно управляет lock-файлом, target-каталогом и командами для нескольких пакетов, но каждый member остаётся отдельным пакетом/crate со своим API. Удаление Cargo.lock гарантирует воспроизводимый выбор самых новых совместимых версий. Следовательно, для «Рабочие пространства workspace» не понадобилось бы явное предусловие. Cargo.lock не участвует в воспроизводимости и всегда должен отсутствовать даже у приложений. Тогда различия между обычным и граничным случаем для «Рабочие пространства workspace» исчезли бы. Workspace объединяет пакеты в один crate и общее пространство имён. Тогда различия между обычным и граничным случаем для «Рабочие пространства workspace» исчезли бы.

Вопрос 7 из 30

Какой вариант исправления сохраняет контракт механизма «Безопасность и производительность»?

[build-dependencies]
codegen-helper = "*"

Сделать все элементы вокруг `build` публичными, чтобы не разбирать фактическую границу модуля и путь внешнего пользователя. Включить весь набор возможностей сборки по умолчанию, чтобы скрыть различия путей и условно компилируемых элементов. Удалять Cargo.lock перед каждой сборкой, чтобы зависимости всегда были свежими. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Тогда поведение «Безопасность и производительность» при раннем выходе выводили бы из обычного пути. Ограничить версию, проверять Cargo.lock и источник, минимизировать build scripts/proc macros и запускать аудит зависимостей и лицензий. Проверять только сборку с набором features all; отдельные и минимальные комбинации не нужны. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым.

Вопрос 8 из 30

Какой вариант исправляет договор функции, а не только сообщение компилятора?

[workspace]
members = ["crates/core", "crates/cli"]
resolver = "3"

[workspace.dependencies]
serde = "1"

Выносить общие версии и lints в workspace, но не создавать скрытые циклические зависимости между пакетами; проверять каждый публичный crate отдельно. Скопировать общий исходник в каждый пакет workspace вместо выделения внутреннего crate. При каждом таком вызове появляется отдельный владелец и оплачивается копирование данных. Сделать все элементы вокруг `workspace` публичными, чтобы не разбирать фактическую границу модуля и путь внешнего пользователя. Удалять Cargo.lock перед каждой сборкой, чтобы зависимости всегда были свежими. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Такое рассуждение переносило бы вывод о «Рабочие пространства workspace» на неисполненную ветвь. Скрыть несовместимые зависимости под одинаковым именем без переименования package. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым.

Вопрос 9 из 30

Как привести сигнатуру и фактическое время жизни данных в соответствие?

[features]
default = ["json"]
json = ["dep:serde_json"]
metrics = []

[dependencies]
serde_json = { version = "1", optional = true }

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

Вопрос 10 из 30

Какой вариант делает путь ошибки явным для вызывающего кода?

# Минимальная матрица:
cargo test --workspace
cargo test --workspace --all-features
cargo test --workspace --no-default-features
cargo doc --workspace --no-deps

Скопировать общий исходник в каждый пакет workspace вместо выделения внутреннего crate. При каждом таком вызове появляется отдельный владелец и оплачивается копирование данных. Следовательно, для «Тестирование и инструменты Cargo» не понадобилось бы явное предусловие. Определить поддерживаемые комбинации явно, добавить cargo fmt --check, clippy с выбранным уровнем предупреждений, package и минимальную версию toolchain. Сделать все элементы вокруг `cargo` публичными, чтобы не разбирать фактическую границу модуля и путь внешнего пользователя. Проверять только сборку с набором features all; отдельные и минимальные комбинации не нужны. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Тогда различия между обычным и граничным случаем для «Тестирование и инструменты Cargo» исчезли бы. Удалять Cargo.lock перед каждой сборкой, чтобы зависимости всегда были свежими. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Контракт «Тестирование и инструменты Cargo» считался бы одинаковым при любом состоянии входа.

Вопрос 11 из 30

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

Cargo.lock не участвует в воспроизводимости и всегда должен отсутствовать даже у приложений. Следовательно, для «Безопасность и производительность» не понадобилось бы явное предусловие. Features Cargo являются переключателями времени выполнения и могут безопасно менять публичные типы после запуска. Build scripts и procedural macros выполняются на машине сборки, поэтому их риск шире обычной runtime-библиотеки, даже если код приложения безопасен. Удаление Cargo.lock гарантирует воспроизводимый выбор самых новых совместимых версий. Pub делает элемент доступным любому crate независимо от видимости родительских модулей. Тогда поведение «Безопасность и производительность» при раннем выходе выводили бы из обычного пути.

Вопрос 12 из 30

Какой узкий вывод следует из проверки `cargo check --no-default-features`?

[features]
default = ["json"]
json = ["dep:serde_json"]
metrics = []

[dependencies]
serde_json = { version = "1", optional = true }

# cargo check --no-default-features
# cargo check --all-features

Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Успешный запуск подтверждает корректность не только этого пути, но и остальных ветвей программы. Дополнительный сценарий вокруг `cargo check --no-default-features` при таком толковании уже не требуется. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Две команды ловят зависимость кода от неявного default feature и конфликты при одновременном включении всех поддерживаемых возможностей. Одного успешного примера достаточно, чтобы считать проверенными и невыполненные ветви контракта. Тогда поведение «Возможности сборки features» при раннем выходе выводили бы из обычного пути.

Вопрос 13 из 30

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

[workspace]
members = ["crates/core", "crates/cli"]
resolver = "3"

[workspace.dependencies]
serde = "1"

# cargo test --workspace
# cargo package -p corelib

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

Вопрос 14 из 30

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

Cargo.lock не участвует в воспроизводимости и всегда должен отсутствовать даже у приложений. Такое рассуждение переносило бы вывод о «Воспроизводимость» на неисполненную ветвь. Удаление Cargo.lock гарантирует воспроизводимый выбор самых новых совместимых версий. Feature Cargo автоматически включается при наличии одноимённого модуля. Lock-файл фиксирует выбранные версии и checksums, но не фиксирует компилятор, системные библиотеки, build scripts и переменные окружения. Features Cargo являются переключателями времени выполнения и могут безопасно менять публичные типы после запуска. Контракт «Воспроизводимость» считался бы одинаковым при любом состоянии входа.

Вопрос 15 из 30

Какой случай чаще всего обнаруживает скрытую ошибку в реализации «Рабочие пространства workspace»?

Успешная сборка workspace не гарантирует, что отдельный публикуемый crate содержит все нужные файлы и версии; cargo package следует запускать по каждому пакету. Обновление lock-файла не требует просмотра транзитивных изменений и контрольных сумм. Цикл зависимостей между пакетами workspace допустим, когда функции не вызывают друг друга. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Публичный путь остаётся совместимым после перемещения типа между модулями, если имя типа не изменилось. Тогда различия между обычным и граничным случаем для «Рабочие пространства workspace» исчезли бы. Сборка одной целевой платформы подтверждает корректность всех target-specific секций манифеста. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение.

Вопрос 16 из 30

Какое объяснение механизма «Тестирование и инструменты Cargo» не смешивает компиляцию и выполнение?

Cargo.lock не участвует в воспроизводимости и всегда должен отсутствовать даже у приложений. Следовательно, поведение `cargo test --workspace` считалось бы одинаковым для всех допустимых типов. Features Cargo являются переключателями времени выполнения и могут безопасно менять публичные типы после запуска. Проверку ошибки для «Тестирование и инструменты Cargo» при таком подходе заменили бы успешным примером. Cargo-команды проверяют разные контракты: check — типы, test — поведение, doc — публичную документацию, package — состав публикации, tree — разрешённый граф. Удаление Cargo.lock гарантирует воспроизводимый выбор самых новых совместимых версий. В результате «Тестирование и инструменты Cargo» считали бы безопасным и на путях, которых пример не выполняет. Feature Cargo автоматически включается при наличии одноимённого модуля. Проверку ошибки для «Тестирование и инструменты Cargo» при таком подходе заменили бы успешным примером.

Вопрос 17 из 30

Какие данные останутся доступными после ключевой операции?

[build-dependencies]
codegen-helper = "*"

Wildcard для исполняемой build-зависимости делает сборку невоспроизводимой и увеличивает риск цепочки поставки: новый релиз может выполнить произвольный код. Код компилируется, но резолвер зависимостей загружает новую версию при каждом вызове функции. Значит, выполнение должно пройти через `массив` без изменения сигнатуры. Код пройдёт проверку компилятора: feature Cargo автоматически включается при наличии одноимённого модуля. Rust примет этот код, поскольку pub делает элемент доступным любому crate независимо от видимости родительских модулей. Компиляция завершится успешно: удаление Cargo.lock гарантирует воспроизводимый выбор самых новых совместимых версий.

Вопрос 18 из 30

На какое правило следует опираться при ревью кода по теме «Возможности сборки features»?

Cargo.lock не участвует в воспроизводимости и всегда должен отсутствовать даже у приложений. Следовательно, поведение `[features]` считалось бы одинаковым для всех допустимых типов. Features Cargo являются переключателями времени выполнения и могут безопасно менять публичные типы после запуска. Поэтому ошибочный сценарий вокруг «Возможности сборки features» не проверяли бы отдельно. Feature Cargo автоматически включается при наличии одноимённого модуля. Поэтому ошибочный сценарий вокруг «Возможности сборки features» не проверяли бы отдельно. Workspace превращает пакеты в единый crate с одной библиотечной границей. Из этого следовало бы, что иной порядок операций для «Возможности сборки features» ничего не меняет. Cargo объединяет features одной версии пакета по графу зависимостей; включённая возможность обычно не может быть надёжно выключена downstream-зависимостью.

Вопрос 19 из 30

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

[build-dependencies]
codegen-helper = "*"

# cargo tree -d
# cargo build --timings
# cargo audit / cargo deny (внешние инструменты)

Проверка подтверждает производительность решения, даже если в ней нет измерения времени, памяти или аллокаций; результат проверки с `build` предлагается переносить на все остальные ветви. Если код принят компилятором, отдельное наблюдение за результатом этого сценария избыточно. Нормальный результат на одном входе позволяет распространить тот же вывод на отмену и частичное выполнение. По этой логике отдельная проверка «Безопасность и производительность» на другом входе считалась бы лишней. Дерево и timings находят дубли и дорогие crate, а аудит зависимостей проверяет известные уязвимости и политики цепочки поставки. Результат можно считать доказательством свойства языка, даже если он зависит от конкретной библиотеки или платформы.

Вопрос 20 из 30

Какой риск остаётся после успешной компиляции кода по теме «Манифест Cargo.toml»?

Опциональная зависимость не влияет на граф и время сборки, пока её API не вызывается. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Цикл зависимостей между пакетами workspace допустим, когда функции не вызывают друг друга. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. По этой логике отдельная проверка «Манифест Cargo.toml» на другом входе считалась бы лишней. Если default-набор features собирается, остальные комбинации можно считать эквивалентными. Добавление pub не расширяет поверхность совместимости и не влияет на semver. Указанный rust-version должен быть совместим с edition и зависимостями; зависимость может незаметно поднять фактический MSRV без изменения собственного исходника.

Вопрос 21 из 30

Что можно считать доказанным после успешного выполнения `[package]`?

[package]
name = "corelib"
version = "1.2.0"
edition = "2024"
rust-version = "1.85"

# cargo package --list
# cargo metadata --no-deps

Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Дополнительный сценарий вокруг `[package]` при таком толковании уже не требуется. Если обычный путь проходит, поведение при отмене и повторном входе можно считать следствием того же теста. Первая команда показывает состав публикуемого архива, вторая — вычисленную структуру пакета и targets без сборки зависимостей. Отсутствие сообщения инструмента означает, что опасная ветвь была выполнена и признана корректной. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно.

Вопрос 22 из 30

Какое предусловие «Возможности сборки features» необходимо записать явно?

Цикл зависимостей между пакетами workspace допустим, когда функции не вызывают друг друга. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Тогда различия между обычным и граничным случаем для «Возможности сборки features» исчезли бы. Проверка только default-набора пропускает поломки no-default-features и all-features; комбинационный взрыв требует осмысленной матрицы поддерживаемых наборов. Сборка одной целевой платформы подтверждает корректность всех target-specific секций манифеста. Тогда поведение «Возможности сборки features» при раннем выходе выводили бы из обычного пути. Если default-набор features собирается, остальные комбинации можно считать эквивалентными. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Опциональная зависимость не влияет на граф и время сборки, пока её API не вызывается.

Вопрос 23 из 30

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

Обновление lock-файла не требует просмотра транзитивных изменений и контрольных сумм. Проверку ошибки для «Тестирование и инструменты Cargo» при таком подходе заменили бы успешным примером. Если default-набор features собирается, остальные комбинации можно считать эквивалентными. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Опциональная зависимость не влияет на граф и время сборки, пока её API не вызывается. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Следовательно, для «Тестирование и инструменты Cargo» не понадобилось бы явное предусловие. Запуск clippy с -D warnings без зафиксированного toolchain может ломать CI от новых lint; политику обновления компилятора нужно отделить от обычной проверки изменений. Минимальная поддерживаемая версия Rust определяется только текущим локальным компилятором. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение.

Вопрос 24 из 30

Что отделяет корректное применение «Манифест Cargo.toml» от случайно работающего решения?

Резолвер выбирает отдельную версию зависимости для каждого вызова функции. Из этого следовало бы, что иной порядок операций для «Манифест Cargo.toml» ничего не меняет. Cargo.toml описывает пакет, targets, зависимости, features, profiles и metadata; пакет может содержать библиотечный и несколько бинарных crate. Cargo.lock не участвует в воспроизводимости и всегда должен отсутствовать даже у приложений. Из этого следовало бы, что иной порядок операций для «Манифест Cargo.toml» ничего не меняет. Features Cargo являются переключателями времени выполнения и могут безопасно менять публичные типы после запуска. Feature Cargo автоматически включается при наличии одноимённого модуля.

Вопрос 25 из 30

Какой вывод о выполнении `[package]` подтверждает код?

[package]
name = "corelib"
version = "1.2.0"
edition = "2024"
rust-version = "1.85"

Код считается допустимым, потому что feature Cargo автоматически включается при наличии одноимённого модуля. Из этого следовало бы, что иной порядок операций для «Манифест Cargo.toml» ничего не меняет. Код компилируется, но резолвер зависимостей загружает новую версию при каждом вызове функции. Значит, выполнение должно пройти через `[package]` без изменения сигнатуры. Код пройдёт проверку компилятора: pub делает элемент доступным любому crate независимо от видимости родительских модулей. До выполнения код дойдёт без ошибки компиляции, поскольку удаление Cargo.lock гарантирует воспроизводимый выбор самых новых совместимых версий. Манифест объявляет пакет, edition и минимальную поддерживаемую версию компилятора; rust-version позволяет Cargo раньше отклонить слишком старый toolchain.

Вопрос 26 из 30

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

Если default-набор features собирается, остальные комбинации можно считать эквивалентными. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Следовательно, для «Безопасность и производительность» не понадобилось бы явное предусловие. Большое число features и дубли версий повышают время компиляции и размер; без cargo tree и timings причина может быть скрыта за удобным facade-crate. Цикл зависимостей между пакетами workspace допустим, когда функции не вызывают друг друга. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Опциональная зависимость не влияет на граф и время сборки, пока её API не вызывается. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Тогда различия между обычным и граничным случаем для «Безопасность и производительность» исчезли бы. Обновление lock-файла не требует просмотра транзитивных изменений и контрольных сумм. По этой логике отдельная проверка «Безопасность и производительность» на другом входе считалась бы лишней.

Вопрос 27 из 30

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

[package]
name = "corelib"
version = "1.2.0"
edition = "2024"
rust-version = "1.85"

Сделать все элементы вокруг `package` публичными, чтобы не разбирать фактическую границу модуля и путь внешнего пользователя. Скрыть несовместимые зависимости под одинаковым именем без переименования package. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Такое рассуждение переносило бы вывод о «Манифест Cargo.toml» на неисполненную ветвь. Удалять Cargo.lock перед каждой сборкой, чтобы зависимости всегда были свежими. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Поэтому ошибочный сценарий вокруг «Манифест Cargo.toml» не проверяли бы отдельно. Скопировать реализацию в соседний модуль или пакет, вместо того чтобы исправить видимость и структуру зависимостей. Поддерживать edition и MSRV как явный контракт, проверять публикационный пакет cargo package и не включать секреты или ненужные артефакты.

Вопрос 28 из 30

Что напечатает или вернёт показанный код?

# Cargo.lock зафиксирован в репозитории приложения.
# cargo build --locked

До выполнения код дойдёт без ошибки компиляции, поскольку feature Cargo автоматически включается при наличии одноимённого модуля. Код пройдёт проверку компилятора: импорт use меняет исходную видимость элемента для всех модулей. Компилятор отвергнет фрагмент, поскольку зависимость указана через workspace.dependencies. До последней строки и наблюдаемого результата программа при таком разборе не доходит. --locked требует использовать существующий lock-файл без его изменения и завершится ошибкой, если манифест требует переразрешения зависимостей. Rust примет этот код, поскольку удаление Cargo.lock гарантирует воспроизводимый выбор самых новых совместимых версий.

Вопрос 29 из 30

Какой дефект способен воспроизвести тест `cargo test --workspace`?

# Минимальная матрица:
cargo test --workspace
cargo test --workspace --all-features
cargo test --workspace --no-default-features
cargo doc --workspace --no-deps

# cargo tree -e features
# cargo tree -d

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

Вопрос 30 из 30

Как Rust выполнит этот фрагмент о механизме «Возможности сборки features»?

[features]
default = ["json"]
json = ["dep:serde_json"]
metrics = []

[dependencies]
serde_json = { version = "1", optional = true }

Код не пройдёт проверку: зависимость указана через workspace.dependencies. До последней строки и наблюдаемого результата программа при таком разборе не доходит. Поэтому ошибочный сценарий вокруг «Возможности сборки features» не проверяли бы отдельно. Код пройдёт проверку компилятора: workspace объединяет пакеты в один crate и общее пространство имён. Feature json включает optional dependency через dep:serde_json; отключение default-features уберёт её, если никакая другая возможность не активирует зависимость. Код компилируется, но выбор feature можно менять для уже запущенного бинарного файла. Значит, выполнение должно пройти через `[features]` без изменения сигнатуры. Фрагмент успешно соберётся: feature Cargo автоматически включается при наличии одноимённого модуля.