Rust 1.99.1: исправления FFI и проверка готовой программы

Rust 1.99.1 исправляет регрессии, в том числе неверную передачу результата bool через FFI на x86_64. Для владельца программы задача состоит не только в обновлении компилятора: нужно установить, какой сборкой инструментария создан именно тот файл, который получают пользователи. Версия Rust на компьютере разработчика этого не доказывает.

Что исправили и почему это касается поставки

Релиз Rust 1.99.1 от 15 октября 2026 года описывает три регрессии: отсутствие wcslen у части целевых платформ, возврат bool через FFI на x86_64 и загрузку libLLVM линковщиком rust-lld в определённом способе запуска на macOS. Это разные области проверки, а не сообщение, что любая программа на Rust работала неправильно.

Двумя неделями ранее, 1 октября, вышел Rust 1.99.0, где среди новшеств появилась возможность определять вариативные функции с C ABI. Не следует смешивать новую возможность с исправлениями последующего точечного выпуска. Сам анонс 1.99.1 называет регрессии прежних выпусков, не приписывая все три одной версии.

Как перевести список исправлений в вопросы к продукту

Таблица — наша схема проверки поставки, а не полный перечень затронутых продуктов. Если команда не использует описанную границу FFI или соответствующий target, это нужно записать как результат анализа зависимостей. Не надо придумывать неисправность ради формального обновления отчёта.

Учебный пример: компилятор новый, библиотека старая

Представим условное настольное приложение с модулем расчёта на Rust. Разработчик обновил локальный инструментарий, а установщик продолжает брать библиотеку из прежнего каталога результатов сборки. Проверка версии компилятора проходит, но пользователь получает тот же файл. Это вымышленный пример ошибки выпуска, не случай клиента студии.

Разрешить сомнение помогает цепочка происхождения: исходный код, параметры целевой платформы, задание сборки, полученная библиотека, состав установщика. Контрольная сумма позволяет сопоставить конкретные файлы. Она не оценивает правильность программы сама по себе, зато не даёт незаметно заменить предмет проверки.

FFI проверяется вместе с вызывающей стороной

Успешная компиляция не подтверждает поведение внешнего интерфейса. Для проектной проверки подготовьте разрешённый тест, в котором реальная вызывающая сторона получает оба ожидаемых логических результата. Отдельно согласуйте, что считать правильным ответом при ошибке. Не подменяйте такую проверку демонстрацией на другом интерфейсе.

Часть зависимостей может поставляться готовыми файлами. Тогда нужен ответ поставщика о происхождении библиотеки и применимой исправленной сборке. Переключение Rust в основном репозитории не является свидетельством пересборки стороннего компонента. Не требуется объявлять такой компонент уязвимым без подтверждения затронутого условия.

Что сохранить при следующем выпуске

1. Перечислите выпускаемые платформы и внешние интерфейсы Rust-модулей.
2. Сопоставьте их с условиями исправлений из анонса.
3. Выберите поддерживаемый инструментарий с нужными исправлениями, проверив последующие выпуски.
4. Пересоберите затронутые компоненты в контролируемой среде.
5. Проверьте внешний вызов на полученном файле.
6. Сопоставьте проверенный компонент с содержимым дистрибутива.
7. Сохраните подтверждения и список ещё не проверенных поставок.

Номер 1.99.1 в этой новости обозначает конкретное исправление, а не бессрочную рекомендацию устанавливать именно эту версию. Перед плановым обновлением снова проверьте актуальные выпуски. Переход на более новый инструментарий также требует проверки вашего продукта.

В разработке настольной программы закрепляйте состав поставки как часть приёмки. Для интеграции компонентов описывайте внешние типы и ошибки, а при доработке существующего решения передавайте сведения о сборке вместе с исходниками. Тогда вопрос «исправление дошло до клиента?» получает проверяемый ответ.