Модули и видимость — бесплатный тест онлайн

Вопрос 1 из 20

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

use std::fmt::Result as FmtResult;
use std::io::Result as IoResult;
fn format() -> FmtResult { Ok(()) }
fn read() -> IoResult<()> { Ok(()) }

Заменить явные импорты на use crate::* и положиться на порядок разрешения имён. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Сделать все элементы вокруг `std::fmt::Result` публичными, чтобы не разбирать фактическую границу модуля и путь внешнего пользователя. Импортировать конфликтующие имена с as или оставить квалифицированные пути; wildcard-импорт не решает неоднозначность и ухудшает ревью. Использовать путь через файловую систему в коде Rust вместо дерева модулей. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Зашить абсолютный путь к данные этого фрагмента в каждом месте использования, не сохраняя прежние переэкспорты и публичные пути. Проверку ошибки для `format` при таком подходе заменили бы успешным примером.

Вопрос 2 из 20

Как убрать источник проблемы в коде с `outer::inner`?

mod outer {
    pub mod inner { pub fn value() -> i32 { 7 } }
}
fn main() { println!("{}", outer::inner::value()); }

Размещать модули по смысловым границам и объявлять их из родителя; не считать файловую систему автоматическим деревом модулей без mod-объявлений. Сделать все элементы вокруг `mod` публичными, чтобы не разбирать фактическую границу модуля и путь внешнего пользователя. Включить весь набор возможностей сборки по умолчанию, чтобы скрыть различия путей и условно компилируемых элементов. Сделать все модули, поля и вспомогательные типы pub, чтобы больше не сталкиваться с ошибками видимости. Использовать путь через файловую систему в коде Rust вместо дерева модулей. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. В результате `value` считали бы безопасным и на путях, которых пример не выполняет.

Вопрос 3 из 20

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

mod account {
    pub struct User { pub name: String, secret: String }
    impl User { pub fn new(name: String) -> Self { Self { name, secret: "x".into() } } }
}
let u = account::User::new("Ada".into());
println!("{}", u.name);

Проверка типов пропустит этот путь: feature Cargo автоматически включается при наличии одноимённого модуля. Код компилируется, но видимость проверяется только при первом обращении во время выполнения. Значит, выполнение должно пройти через `account::User` без изменения сигнатуры. Код считается допустимым, потому что pub делает элемент доступным любому crate независимо от видимости родительских модулей. Код компилируется: тип, конструктор и поле name публичны, а закрытое поле secret не мешает использовать созданное значение через API. Проверка типов пропустит этот путь: импорт use меняет исходную видимость элемента для всех модулей.

Вопрос 4 из 20

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

Добавление pub не расширяет поверхность совместимости и не влияет на semver. Поэтому ошибочный сценарий вокруг «Модули mod» не проверяли бы отдельно. Файл может существовать на диске, но не участвовать в crate, пока не включён через mod или иной корневой модуль. Если default-набор features собирается, остальные комбинации можно считать эквивалентными. Опциональная зависимость не влияет на граф и время сборки, пока её API не вызывается. Публичный путь остаётся совместимым после перемещения типа между модулями, если имя типа не изменилось.

Вопрос 5 из 20

Какое свойство «Открытая видимость pub» сохранится после небольшого рефакторинга?

Pub делает элемент доступным любому crate независимо от видимости родительских модулей. Следовательно, поведение `account::User` считалось бы одинаковым для всех допустимых типов. Workspace превращает пакеты в единый crate с одной библиотечной границей. Следовательно, поведение `account::User` считалось бы одинаковым для всех допустимых типов. Видимость дочернего элемента не зависит от доступности всех родительских модулей. Поэтому ошибочный сценарий вокруг «Открытая видимость pub» не проверяли бы отдельно. pub управляет доступностью элемента относительно модулей, но публичный тип с закрытыми полями нельзя сконструировать литералом снаружи модуля. Импорт use меняет исходную видимость элемента для всех модулей. Поэтому ошибочный сценарий вокруг «Открытая видимость pub» не проверяли бы отдельно.

Вопрос 6 из 20

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

use std::fmt::Result as FmtResult;
use std::io::Result as IoResult;
fn format() -> FmtResult { Ok(()) }
fn read() -> IoResult<()> { Ok(()) }

Код компилируется: псевдонимы снимают конфликт двух типов Result и делают назначение каждого явным. Код считается допустимым, потому что glob-импорт имеет приоритет над локальными именами и устраняет неоднозначность. Компилятор примет фрагмент: импорт use меняет исходную видимость элемента для всех модулей. Фрагмент не соберётся: путь начинается с crate:: вместо имени текущего файла. Сборка пройдёт, поскольку workspace объединяет пакеты в один crate и общее пространство имён.

Вопрос 7 из 20

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

Публичный путь остаётся совместимым после перемещения типа между модулями, если имя типа не изменилось. Цикл зависимостей между пакетами workspace допустим, когда функции не вызывают друг друга. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. В результате «Структура crate» считали бы безопасным и на путях, которых пример не выполняет. Если default-набор features собирается, остальные комбинации можно считать эквивалентными. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Проверку ошибки для «Структура crate» при таком подходе заменили бы успешным примером. Циклические логические зависимости между модулями разрешаются через общее дерево имён, но часто указывают на неудачную границу ответственности и публичных типов. Добавление pub не расширяет поверхность совместимости и не влияет на semver. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются.

Вопрос 8 из 20

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

// src/lib.rs
pub mod api;
// src/api.rs
pub fn version() -> u8 { 1 }

Такая раскладка подключает src/api.rs как модуль api библиотеки; функция доступна внешнему коду по пути crate_name::api::version. Компиляция завершится успешно: feature Cargo автоматически включается при наличии одноимённого модуля. Проверка типов пропустит этот путь: workspace объединяет пакеты в один crate и общее пространство имён. Код считается допустимым, потому что pub делает элемент доступным любому crate независимо от видимости родительских модулей. Проверку ошибки для `version` при таком подходе заменили бы успешным примером. Компилятор отвергнет фрагмент, поскольку путь начинается с crate:: вместо имени текущего файла.

Вопрос 9 из 20

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

// src/lib.rs
mod parser;
pub use parser::parse;

Одного успешного примера достаточно, чтобы считать проверенными и невыполненные ветви контракта. Контракт `parser::parse` считался бы одинаковым при любом состоянии входа. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Результат можно считать доказательством свойства языка, даже если он зависит от конкретной библиотеки или платформы. Публичный re-export делает parse частью внешнего API, хотя сам модуль parser может оставаться закрытым. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно.

Вопрос 10 из 20

К какому результату приводит последовательность вокруг `outer::inner`?

mod outer {
    pub mod inner { pub fn value() -> i32 { 7 } }
}
fn main() { println!("{}", outer::inner::value()); }

Код пройдёт проверку компилятора: workspace объединяет пакеты в один crate и общее пространство имён. Проверку ошибки для `value` при таком подходе заменили бы успешным примером. Компилятор отвергнет фрагмент, поскольку модуль объявлен в отдельном исходном файле. Такая запись допустима, так как pub делает элемент доступным любому crate независимо от видимости родительских модулей. Код компилируется и печатает 7: mod создаёт модуль, а путь проходит через закрытый inner и публичную функцию. Код компилируется и печатает 7: mod создаёт модуль, а путь проходит через публичный inner и публичную функцию.

Вопрос 11 из 20

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

mod account {
    pub struct User { pub name: String, secret: String }
    impl User { pub fn new(name: String) -> Self { Self { name, secret: "x".into() } } }
}
let u = account::User::new("Ada".into());
println!("{}", u.name);

Сделать все модули, поля и вспомогательные типы pub, чтобы больше не сталкиваться с ошибками видимости. Проверку ошибки для `new` при таком подходе заменили бы успешным примером. Использовать путь через файловую систему в коде Rust вместо дерева модулей. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Контракт `new` считался бы одинаковым при любом состоянии входа. Сделать все элементы вокруг `mod` публичными, чтобы не разбирать фактическую границу модуля и путь внешнего пользователя. Оставить инвариантные поля закрытыми и предоставить конструкторы и методы; pub ставить только на реально поддерживаемую поверхность. Скопировать реализацию в соседний модуль или пакет, вместо того чтобы исправить видимость и структуру зависимостей. Проверку ошибки для `new` при таком подходе заменили бы успешным примером.

Вопрос 12 из 20

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

Если default-набор features собирается, остальные комбинации можно считать эквивалентными. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Добавление pub не расширяет поверхность совместимости и не влияет на semver. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Минимальная поддерживаемая версия Rust определяется только текущим локальным компилятором. По этой логике отдельная проверка «Открытая видимость pub» на другом входе считалась бы лишней. Публичный путь остаётся совместимым после перемещения типа между модулями, если имя типа не изменилось. Тогда различия между обычным и граничным случаем для «Открытая видимость pub» исчезли бы. pub(crate), pub(super) и pub(in path) позволяют сузить аудиторию; простое pub может случайно превратить деталь реализации в стабильный API.

Вопрос 13 из 20

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

Импорт use меняет исходную видимость элемента для всех модулей. Тогда поведение «Импорт имён use» при раннем выходе выводили бы из обычного пути. Workspace объединяет пакеты в один crate и общее пространство имён. Следовательно, для «Импорт имён use» не понадобилось бы явное предусловие. use создаёт удобное имя пути в текущей области и может переименовать его через as; он не копирует и не изменяет сам элемент. Порядок строк use определяет, какое из конфликтующих имён победит. По этой логике отдельная проверка «Импорт имён use» на другом входе считалась бы лишней. Glob-импорт имеет приоритет над локальными именами и устраняет неоднозначность. Следовательно, поведение `std::fmt::Result` считалось бы одинаковым для всех допустимых типов.

Вопрос 14 из 20

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

Публичный путь остаётся совместимым после перемещения типа между модулями, если имя типа не изменилось. Тогда различия между обычным и граничным случаем для «Импорт имён use» исчезли бы. Если default-набор features собирается, остальные комбинации можно считать эквивалентными. По этой логике отдельная проверка «Импорт имён use» на другом входе считалась бы лишней. Добавление pub не расширяет поверхность совместимости и не влияет на semver. Публичный use является re-export и меняет внешний API модуля, тогда как обычный use влияет только на локальное разрешение имён. Опциональная зависимость не влияет на граф и время сборки, пока её API не вызывается. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Тогда поведение «Импорт имён use» при раннем выходе выводили бы из обычного пути.

Вопрос 15 из 20

Как переработать участок с `version`, сохранив требуемое поведение?

// src/lib.rs
pub mod api;
// src/api.rs
pub fn version() -> u8 { 1 }

Использовать путь через файловую систему в коде Rust вместо дерева модулей. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Проверку ошибки для `version` при таком подходе заменили бы успешным примером. Скопировать реализацию в соседний модуль или пакет, вместо того чтобы исправить видимость и структуру зависимостей. Контракт `version` считался бы одинаковым при любом состоянии входа. Скопировать общий исходник в каждый пакет workspace вместо выделения внутреннего crate. При каждом таком вызове появляется отдельный владелец и оплачивается копирование данных. Следовательно, для `version` не понадобилось бы явное предусловие. Держать корень crate в lib.rs или main.rs и явно объявлять дочерние модули; общий код бинарников вынести в библиотечную часть. Сделать все элементы вокруг `src` публичными, чтобы не разбирать фактическую границу модуля и путь внешнего пользователя.

Вопрос 16 из 20

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

mod m { pub(crate) fn internal() {} }
fn call() { m::internal(); }

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

Вопрос 17 из 20

Какое свойство закрепляет сценарий `inner::Item`?

mod inner { pub struct Item; }
pub use inner::Item;

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

Вопрос 18 из 20

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

Crate имеет один корневой модуль; дополнительные бинарники в src/bin создают отдельные binary crates пакета и не делят модули автоматически. Workspace превращает пакеты в единый crate с одной библиотечной границей. Тогда поведение «Структура crate» при раннем выходе выводили бы из обычного пути. Workspace объединяет пакеты в один crate и общее пространство имён. В результате «Структура crate» считали бы безопасным и на путях, которых пример не выполняет. Одинаковое имя feature в двух зависимостях автоматически означает общий глобальный переключатель. В результате «Структура crate» считали бы безопасным и на путях, которых пример не выполняет. Pub делает элемент доступным любому crate независимо от видимости родительских модулей. Поэтому ошибочный сценарий вокруг «Структура crate» не проверяли бы отдельно.

Вопрос 19 из 20

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

Видимость дочернего элемента не зависит от доступности всех родительских модулей. mod вводит модуль в дерево crate; расположение кода в inline-блоке или файле не отменяет правил путей и видимости. Workspace превращает пакеты в единый crate с одной библиотечной границей. Тогда различия между обычным и граничным случаем для «Модули mod» исчезли бы. Workspace объединяет пакеты в один crate и общее пространство имён. Из этого следовало бы, что иной порядок операций для «Модули mod» ничего не меняет. Pub делает элемент доступным любому crate независимо от видимости родительских модулей.

Вопрос 20 из 20

Какой узкий вывод следует из проверки `mylib::api`?

// src/bin/admin.rs
fn main() { println!("{}", mylib::api::version()); }

Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Результат можно считать доказательством свойства языка, даже если он зависит от конкретной библиотеки или платформы. Если обычный путь проходит, поведение при отмене и повторном входе можно считать следствием того же теста. Поэтому ошибочный сценарий вокруг `main` не проверяли бы отдельно. Дополнительный бинарник использует библиотечный crate пакета по его имени, вместо дублирования mod api с отдельной копией дерева. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно.