Мы рады представить новую версию Rust 1.12.1. Rust — это системный язык программирования, нацеленный на безопасную работу с памятью, скорость и параллельное выполнение кода.
Как обычно, вы можете установить Rust 1.12.1 с соответствующей страницы официального сайта, или с помощью rustup выполнив команду rustup update stable.
Что вошло в стабильную версию 1.12.1
Секундочку… один-точка-двенадцать-точка… один?
Несколько недель назад, в анонсе версии 1.12, мы сказали:
Выпуск 1.12 — возможно, самый значительный с момента выпуска 1.0.
И это правда. Одним из важных изменений был масштабный рефакторинг компилятора. Новый бэкенд MIR изменил его архитектуру и некоторые детали реализации. В целом процесс модернизации прошел так:
- Начальная поддержка MIR появилась в ночных сборках Rust 1.6.
- Когда работа была завершена, был добавлен флаг компиляции
--enable-orbit,
что бы разработчики компилятора могли испытать новый бэкенд. - Начиная с октября, мы всегда выполняли сборку MIR, даже если
он не использовался. - Был добавлен параметр командной стоки
-Z orbit, что бы пользователи ночных
сборок могли испытать и использовать MIR вместо этапа компиляции ‘trans’. - После длительного тестирования в течение нескольких месяцев, для версии
Rust 1.12, мы сделали MIR бэкендом по умолчанию. - В Rust 1.13, будет доступен только MIR.
Столь глобальные изменения даются нелегко и очень важны. Поэтому важно сделать всё правильно и тщательно. Вот почему этот процесс идёт так долго. Мы регулярно тестируем компилятор с каждым из пакетов на crates.io, мы просим пользователей проверить -Z orbit на их исходниках, и после шести недель бета-тестирования, так и не возникло существенных проблем. Поэтому мы приняли решение использовать MIR по умолчанию в версии 1.12.
Но большие изменения это всегда риск, хоть мы старались свести его к минимуму. И так, после выхода 1.12, были найдены регрессии, которые мы не смогли обнаружить при тестировании. Не все из них связаны с MIR, просто, при столь масштабных изменениях, легко проявляются ошибки в других местах.
Зачем делать промежуточный релиз?
Учитывая, что у нас шестинедельный цикл выпуска, и мы на полпути к Rust 1.13, почему мы решили выпустить исправление к версии 1.12, а не предложить пользователям просто подождать следующего релиза? Ранее мы говорили нечто подобное: "промежуточные релизы будут происходить только в крайних случаях, таких как уязвимость в стандартной библиотеке".
Мы заботимся не только о стабильности, но и о удобстве использования языка. Мы могли бы сказать всем вам подождать, но мы хотим, чтобы вы знали насколько серьезно мы настроены. Выпуск промежуточного релиза, в данной ситуации, это еще и способ показать наше стремление как можно быстрее исправлять ошибки.
Кроме того, раз уж речь не идёт о проблемах безопасности, это хороший повод попрактиковаться в выпуске промежуточных релизов. Мы никогда не делали этого раньше, и хотя процесс выпуска новой версии частично автоматизирован, но не полностью. Наличие промежуточного релиза позволит выявить ошибки среди других инструментальных средств, например rustup. А еще убедиться, что всё пройдёт по плану, если нам когда-нибудь понадобится, выпустить аварийный релиз из-за проблем безопасности или по любой другой причине.
Это первый промежуточный релиз Rust после выхода Rust 0.3.1, случившегося в 2012, он знаменует 72 недели с момента выпуска Rust 1.0, когда мы приняли наш шестинедельный такт выпуска релизов со строгими гарантиями стабильности. И хотя нам очень жаль, что в 1.12 есть регрессии, мы гордимся стабильностью Rust и будем прилагать все усилия, что бы сделать его платформой на которую можно положиться.
Мы хотим, чтобы Rust был самой надежной в мире платформой для разработки программного обеспечения.
Примечание о тестировании с использованием бета-версий
Есть кое-что, что вы, как пользователь Rust, можете сделать, чтобы помочь нам исправить ошибки как можно раньше: проверяйте свой код с использованием бета-версий! Каждый бета-релиз, это релиз-кандидат следующей стабильной версии, так давайте использовать средства непрерывной интеграции. Так вы сможете сообщить нам о проблемах еще до того как они попадут в стабильный релиз! Это совсем не сложно. Например, если вы используете Travis, добавьте это в свой .travis.yml:
language: rust rust: - stable - beta
И ваши тесты будут выполняться для двух версий компилятора. Кроме того, если вы не хотите, что бы ошибка в бета-версии приводила к ошибке всей сборки, добавьте это:
matrix: allow_failures: - rust: beta
Сборка с бета-версией может стать красной, но ваша стабильная сборка останется зелёной.
Большинство других систем непрерывной интеграции, таких как AppVeyor, должны иметь подобную возможность. Обратитесь к документации используемой вами системы.
Подробности
В версии 1.12.1 было исправлено девять ошибок, естественно, все эти исправления были перенесены в бета-версию 1.13.
- ICE: ‘rustc’ паниковал с сообщением ‘assertion failed: concrete_substs.is_normalized_for_trans()’ #36381
- Путаница с двойным отрицанием и логическими переменными
- rustc 1.12.0 завершался с SIGSEGV при сборке релиза для пакета syn 0.8.0
- Rustc 1.12.0 Windows-сборка пакета ethcore прерывалась с ошибкой LLVM
- 1.12.0: Использовалось много памяти при линковке релиз-версии с отладочной информацией
- Повреждение памяти после перехода на 1.12
- "Let NullaryConstructor = something;" приводит в внутренней ошибке компилятора: "tried to overwrite interned AdtDef"
- Fix ICE: inject bitcast if types mismatch for invokes/calls/stores
- debuginfo: Более правильная обработка spread_arg в MIR-trans.
Кроме того, есть еще четыре регрессии. Мы решили не включать их в 1.12.1 по разным причинам, но постараемся устранить их как можно скорее.
- ICE, возможно, связанный с типами ассоциированных типов?
- Ошибка компиляции пакета использующего большой static phf::Map, на i686-pc-windows-gnu Beta
- Регрессия: ошибка "no method found" при вызове метода дважды, с HRTB impl
- ICE: фиктивный тип sizing_type_of
Полный перечень изменений между версиями 1.12.0 и 1.12.1 здесь.
ссылка на оригинал статьи https://habrahabr.ru/post/314702/
Добавить комментарий