rustycrate.ru

Выпуск Rust 1.34.0

Fri, 12 Apr 2019 00:00:00 +0000

Команда разработчиков Rust рада сообщить о выпуске новой версии Rust, 1.34.0. Rust — это язык программирования, который даёт возможность каждому создавать надёжное и эффективное программное обеспечение.

Если у вас установлена предыдущая версия Rust с помощью rustup, то для обновления Rust до версии 1.34.0 вам достаточно выполнить:

1	$ rustup update stable

Если у вас ещё не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта.

Что вошло в стабильную версию 1.34.0

Основное улучшение этого выпуска это поддержка альтернативных cargo-реестров. Релиз также включает поддержку ? в документационных тестах, некоторые улучшения в #[attribute(...)] и стабилизацию TryFrom. Читайте далее о ключевых вещах или можете посмотреть подробные примечания к выпуску для дополнительной информации.

Альтернативные `cargo` реестры

Ещё до версии 1.0 у Rust был публичный реестр, crates.io. Люди публиковали крейты при помощи cargo publish и легко подключали эти крейты в секции [dependencies] в Cargo.toml.

Однако не все хотят публиковать свои крейты на crates.io. Люди, поддерживающие проекты с закрытым исходным кодом, не могли использовать crates.io, и вместо этого им приходилось указывать git или path в зависимостях. Здесь нет ничего такого для небольших проектов, но если в вашей большой организации есть много крейтов с закрытым кодом, вы теряете преимущества поддержки версионирования, которое есть в crates.io.

Начиная с этого выпуска, Cargo может поддерживать альтернативные реестры. Эти реестры сосуществуют с crates.io, так что вы можете писать программы, которые зависят и от crates.io, и от вашего реестра. Однако крейты на crates.io не могут зависеть от внешнего реестра.

Для использования альтернативных реестров, вы должны добавить следующие строки в .cargo/config. Этот файл может быть в вашей домашней директории (~/.cargo/config) или быть в директории пакета.

[registries]
my-registry = { index = "https://my-intranet:8080/git/index" }

Добавить зависимость из альтернативного реестра легко. Когда вы указываете зависимость в Cargo.toml, используйте ключ registry чтобы Cargo знал что вы хотите получать крейт из альтернативного реестра:

[dependencies]
other-crate = { version = "1.0", registry = "my-registry" }

Как автор крейта, если вы хотите публиковать ваш крейт в альтернативном реестре, первым делом вам надо сохранить аутентификационный токен в ~/.cargo/credentials при помощи команды cargo login:

1	cargo login --registry=my-registry

Далее вы можете использовать флаг --registry для указания реестра, в который будет публиковаться крейт:

1	cargo publish --registry=my-registry

О том, как вы можете запустить свой собственный реестр, вы можете найти в документации.

`?` в документационных тестах

В RFC 1937 было предложено добавить поддержку использования оператора ? в fn main(), #[test] функциях и документационных тестах, позволяя им вернуть Option<T> или Result<T, E> где вариант с ошибкой приводит к ненулевому коду завершения в случае fn main() или упавшему тесту в случае тестов.

Поддержка в fn main() и #[test] была реализована достаточно давно. Однако поддержка в документационных тестах была ограничена тестами, в которых явно присутствовал fn main().

В этом выпуске добавлена полная поддержка ? в документационных тестах. Теперь вы можете написать в ваших документационных тестах такое:

/// ```rust
/// use std::io;
/// let mut input = String::new();
/// io::stdin().read_line(&mut input)?;
/// # Ok::<(), io:Error>(())
/// ```
fn my_func() {}

Внизу документационного теста вам всё равно надо указывать тип ошибки, который будет использован.

Поддержка произвольного потока токенов в пользовательских атрибутах

Процедурные макросы в Rust могут определять пользовательские атрибуты, которые они используют. До текущего момента эти атрибуты были ограничены деревьями путей и литералами в соответствии со следующим синтаксисом:

#[foo(bar)]
#[foo = "bar"]
#[foo = 0]
#[foo(bar = true)]
#[foo(bar, baz(quux, foo = "bar"))]

В отличии от процедурных макросов, эти вспомогательные атрибуты не могли принимать произвольный поток токенов в разделителе, из-за чего вы не могли написать #[range(0..10)] или #[bound(T: MyTrait)]. Крейты процедурных макросов вместо этого использовали строки для синтаксиса, подобного такому, например #[range("0..10")].

С этим выпуском, пользовательские атрибуты #[attr($tokens)] позволяют использовать произвольные токены в $tokens, приводя их в соответствии с макросами. Если вы автор крейта процедурного макроса, пожалуйста проверьте используются ли строки в синтаксисе ваших пользовательских атрибутах и можно ли их заменить на поток токенов.

`TryFrom` и `TryInto`

Трейты TryFrom и TryInto были стабилизированы для поддержки ошибок при преобразовании типов.

Например, from_be_bytes и связанные методы целочисленных типов получают массив, но данные часто читаются через слайсы. Ручное преобразование между слайсами и массивами утомительно. С новыми трейтами это возможно сделать в одну строку с .try_into().

let num = u32::from_be_bytes(slice.try_into()?);

Для преобразований, которые не могут завершиться с ошибкой, таких как u8 в u32, добавлен тип Infallible. За счёт этого TryFrom автоматически реализуется для всего, что реализует типаж From. В будущем, мы надеемся сделать Infallible псевдонимом для типа ! (never).

`fn before_exec` устарела в пользу `unsafe fn pre_exec`

В Unix-подобных системах функция CommandExt::before_exec позволяла вам запланировать выполнение замыкания до вызова exec.

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

Следовательно, функция before_exec должна быть помечена unsafe. В этом выпуске мы пометили fn before_exec устаревшей в пользу unsafe fn pre_exec. При вызове CommandExt::pre_exec вам необходимо убедиться, что замыкание не нарушает инварианты библиотеки создавая не валидные дубликаты. Если вы предоставляете библиотеку, которая находится в подобной before_exec ситуации, подумайте об устаревании и предоставьте альтернативу с unsafe.

Стабилизация в библиотеках

В 1.34.0 расширен набор стабильных атомарных целочисленных знаковых и беззнаковых типов, начиная с 8 битных (AtomicU8) и заканчивая 64 битными.

Ранее были стабилизированы ненулевые беззнаковые целые числа, такие как NonZeroU8. Благодаря этому Option<NonZeroU8> имеет такой же размер, как и u8. В этом выпуске стабилизированы знаковые версии, например NonZeroI8.

Стабилизированы функции iter::from_fn и iter::successors. Первая позволяет создать итератор из FnMut() -> Option<T>. Чтобы итеративно получать элементы из вектора, вы теперь можете написать from_fn(|| vec.pop()). Тем временем вторая функция создаёт новый итератор, где каждый следующий элемент вычисляется на основе предыдущего.

Дополнительно, были стабилизированы следующие API:

Для подробной информации смотрите подробные примечания к выпуску

Шаблон индексирования для нового типа

Tue, 26 Mar 2019 00:00:00 +0000

Аналогично предыдущему посту, мы попробуем добавить типы к коду Rust, который без них прекрасно работает. В этот раз мы попробуем улучшить распространенный подход использования индексов для управления циклическими структурами данных.

Проблема

Часто приходится работать со структурой данных, которая содержит циклические ссылки вида: объект foo ссылается на bar, который ссылается baz, который в свою очередь ссылается на foo. Учебный пример здесь представляет собой граф вершин и ребер. Однако на практике истинные графы встречаются редко. Вместо этого, вы скорее всего увидите дерево с указателями на родителей, которое содержит много тривиальных циклов, и иногда неявные циклические графы: Сотрудник (Employee) может быть руководителем Отдела (Department), и в Отделе (Department) есть сотрудники Vec<Employee>. Это что-то вроде замаскированного графа: в обычных графах все вершины одного типа, а вот Сотрудник (Employee) и Отдел (Department) - это разные типы.

Работать с такими структурами данных сложно на любом языке. Прибывать в ситуации, когда A указывает на B, который указывает на A, некоторая форма изменчивости обязательна. Действительно, любой из объектов A или B может быть создан первым, и поэтому он может не сразу после создания указывать на другой объект. Вы можете спрятать изменяемость с помощью let rec, как в OCaml, или ленивости как в Haskell, но она ни куда девается.

Rust старается обнаруживать проблемы такого вида во время компиляции, поэтому реализация таких графов в Rust является сложной задачей. Три обычно применяемых подхода:

Подсчет ссылок, более подробно смотрите у nrc,
Арена и реальные циклические ссылки, объяснение от simonsapin (это очень хороший пост!),
Арена целочисленные индексы, объяснение от nikomatsakis.

(по-видимому, переписывание учебника по монадам в Haskell для Rust приводит к записям в блоге про графы).

Лично мне больше всего нравится подход с индексами, но с ним возникает другая проблема. С ссылками, вы имеете foo типа &Foo, и сразу понятно что это такое и что вы можете с этим сделать. С индексами, однако, у вас есть foo: usize, и не очевидно, что вы каким-то образом можете получить Foo. Даже хуже, если индексы используются для двух типов объектов, таких как Foo и Bar, вы можете в конечном итоге получить thing: usize. При написании кода с использованием usize на самом деле работает довольно хорошо (хотя я не думаю, что когда-либо использовал неправильный тип индекса), чтение его сложнее, потому что usize гораздо менее информативно о том, что вы могли бы сделать с полученным значением.

Трюк с новым типом (Newtype)

Один из способов обойти эту проблему - это сделать обертку над usize:

struct Foo;

#[derive(Debug, Copy, Clone, Ord, PartialOrd, Eq, PartialEq, Hash)]
struct FooIdx(usize);

struct Arena {
    foos: Vec<Foo>,
}

impl Arena {
    fn foo(&self, foo: FooIdx) -> &Foo {
        &self.foos[foo.0]
    }
}

Здесь, “надо использовать FooIdx в Vec<Foo>”, это только соглашение. Одно из достоинств Rust заключается в том, что мы можем превратить это соглашение в свойство, проверенное во время проверки типа. Путем добавления соответствующей реализации, мы сможем индексировать Vec<Foo> с помощью FooIdx напрямую:

#[test]
fn direct_indexing(foos: Vec<Foo>, idx: FooIdx) {
    let _foo: &Foo = &foos[idx];
}

Реализация выглядит так:

use std::ops;

impl ops::Index<FooIdx> for Vec<Foo> {
    type Output = Foo;

    fn index(&self, index: FooIdx) -> &Foo {
        &self[index.0]
    }
}

Последовательность

Интересно разобраться, почему эта реализация вообще разрешена языком. В Rust типы, типажи и реализации разделены. Это создает проблемы: что если есть два блока impl для данной пары (типаж, тип)? Очевидный выбор - запретить иметь два impls, и это именно, то что делает Rust.

На самом деле сложно соблюдать это ограничение! Самое простое правило “ошибка, если набор пакетов содержит повторяющиеся impls” имеет серьезные недостатки. Прежде всего, это глобальная проверка, которая требуется знание всех скомпилированных пакетов. Эта проверка откладывается до более поздних стадий компиляции. Эта проблема также создает проблемы с зависимостями, потому что два совершенно несвязанных пакета могут не компилироваться, если одновременно присутствует impl для пары (типаж, тип). Более того, компилятор сам не решит проблему, т. к. у него нет всей информации обо всех пакетах. Например, можно загрузить дополнительный код во время выполнения через динамические библиотеки и могут произойти всякие плохие штуки, если ваша программа и динамическая библиотека содержат дублирующиеся реализации.

Для того чтобы свободно комбинировать пакеты, мы хотим гораздо более сильное свойство: не только текущее множество скомпилированных пакетов, но и все существующие и даже будущие пакеты не должны нарушать ограничение на одну реализацию типажа. Как это в дальнейшем проверить? При публикации пакета на crates.io через cargo publish должно выдаваться предупреждение о конфликте реализации impl для пары (типаж, тип) с уже опубликованными пакетами?

К счастью, и это потрясающе красиво, можно нивелировать это всеобъемлющее свойство до локального. В самом простом виде, мы может поместить ограничение, что impl Foo for Bar может появиться либо в пакете, который определяет Foo, или в том, который определяет Bar. Важно то, какой из них определяет impl, должен использовать другой, что дает возможность обнаружить конфликт.

Это все действительно изящно, но мы только что определили Index для Vec, и оба - и Index и Vec из стандартной библиотеки! Как это возможно? Хитрость в том, что Index имеет параметр типа: trait Index<Idx: ?Sized>. Это шаблон для типажа, и мы получаем “реальный” типаж, когда мы подставляем параметр типа. Поскольку FooIdx является локальным типом, итоговый Index<FromIdx> тоже считается локальным. Точные правила здесь довольно сложны, RFC объясняет их довольно хорошо.

Больше impls

Поскольку Index<FooIdx> и Index<BarIdx> разные типажи, один тип может реализовать их оба. Это удобно для контейнеров которые содержат различные типы:

struct Arena {
    foos: Vec<Foo>,
    bars: Vec<Bar>,
}

impl ops::Index<FooIdx> for Arena { ... }

impl ops::Index<BarIdx> for Arena { ... }

Также полезно определить арифметические операции и преобразования для новых типизированных индексов. Я собрал typed_index_derive, чтобы автоматизировать этот шаблон через процедурный макрос, конечный результат выглядит следующим образом:

#[macro_use]
extern crate typed_index_derive;

struct Spam(String);

#[derive(
    // Обычно выводит типичные типажи для структур
    Debug, Copy, Clone, Ord, PartialOrd, Eq, PartialEq, Hash,

    TypedIndex
)]
#[typed_index(Spam)] // индексирует `&[Spam]`
struct SpamIdx(usize); // может быть `u32` вместо `usize`

fn main() {
    let spams = vec![Spam("foo".into()), Spam("bar".into()), Spam("baz".into())];

    // Преобразования между `usize` и `SpamIdx`
    let idx: SpamIdx = 1.into();
    assert_eq!(usize::from(idx), 1);

    // Индексирование `Vec<Spam>` с помощью `SpamIdx`, `IndexMut` тоже работает
    assert_eq!(&spams[idx].0, "bar");

    // Индексировать `Vec<usize>` нельзя, как и задумывалось
    // vec![1, 2, 3][idx]
    // error: slice indices are of type `usize` or ranges of `usize`

    // Можно прибавлять `usize` или вычитать его из индекса
    assert_eq!(&spams[idx - 1].0, "foo");

    // Разность между двумя индексами выраженная через `usize`
    assert_eq!(idx - idx, 0usize);
}

Обсуждение /r/rust.

Выпуск Rust 1.33.0

Thu, 28 Feb 2019 00:00:00 +0000

Команда разработчиков Rust рада сообщить о выпуске новой версии Rust, 1.33.0. Rust — это язык программирования, который дает возможность каждому создавать надежное и эффективное программное обеспечение.

Если у вас установлена предыдущая версия Rust с помощью rustup, то для обновления Rust до версии 1.33.0 вам достаточно выполнить:

1	$ rustup update stable

Если у вас еще не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта. С подробными примечаниями к выпуску Rust 1.33.0 можно ознакомиться на GitHub.

Что вошло в стабильную версию 1.33.0

Основные улучшения этого выпуска: значительное расширение возможностей const fn и стабилизация нового Pin API.

Расширение возможностей `const fn`

const fn теперь умеет гораздо больше, а именно:

неопровержимое (irrefutable) сопоставление с образцом (например, const fn foo((x, y): (u8, u8)) { ... })
let привязки (например, let x = 1;)
изменяемые let привязки (например, let mut x = 1;)
выражения присваивания (например x = y) и операторов присваивания (например, x += y), включая присваивание проекциям (например, полю структуры или результату оператора индексирования - x[3] = 42)
инструкции выражений (expression statements) (например, 3;)

Еще теперь можно вызывать “const unsafe fn” из “const fn”, например:

const unsafe fn foo() -> i32 { 5 }
const fn bar() -> i32 {
    unsafe { foo() }
}

Благодаря этим улучшениям стало возможным объявить константными большое количество функций стандартной библиотеки. Они перечислены ниже в библиотечной секции.

Pin API

Данный выпуск привносит в язык новый механизм, представленный типом std::pin::Pin<P> и маркерным типажом Unpin. Основная идея подробно описана в документации “std::pin” модуля:

Иногда может быть полезно запретить перемещение объекта, т.е. гарантировать неизменность его адреса в памяти. Основным сценарием использования такой возможности являются самоссылающиеся структуры, поскольку перемещение таких объектов приведет к инвалидации указателей, что может привести к неопределенному поведению (UB).

Pin<P> гарантирует, что объект, на который ссылается любой указатель типа P, имеет неизменное расположение в памяти, т.е. он не может быть перемещен и его память не может быть освобождена. Такие значения называются “закрепленными” (“pinned”).

Ожидается, что этот механизм будет использоваться в основном авторами библиотек, поэтому мы сейчас не станем погружаться глубже в детали (с которыми можно ознакомиться в документации по ссылке выше). Однако, стабилизация этого API является важным событием для всех пользователей Rust, потому что является ключевым этапом на пути к очень ожидаемому async/await. За статусом оставшейся работы в этом направлении можно следить на areweasyncyet.rs.

Импортировать как `_`

Теперь можно импортировать сущности как _. Это позволяет импортировать реализации типажа без занесения его имени в текущее пространство имен, например:

use std::io::Read as _;

// Тут не возникнет конфликта имен:
pub trait Read {}

Подробности смотрите в примечаниях к выпуску.

Стабилизация стандартной библиотеки

Вот список всего, что стало константным:

Кроме того, стабилизированы следующие API:

unix::FileExt::read_exact_at и unix::FileExt::write_all_at
Option::transpose и Result::transpose
convert::identity
Вышеупомянутые pin::Pin и marker::Unpin
marker::PhantomPinned
Vec::resize_with и VecDeque::resize_with
Duration::as_millis, Duration::as_micros, и Duration::as_nanos

Подробности смотрите в примечаниях к выпуску.

Улучшения в Cargo

Теперь cargo пересобирает крейт, если какой-то из его файлов был изменен во время изначальной сборки.

Подробности смотрите в примечаниях к выпуску.

Crates.io

Как было объявлено ранее, начиная с этого выпуска crates.io будет требовать подтверждения почтового адреса для публикации крейтов. Начиная с 2019-03-01 00:00 UTC выполнение cargo publish будет завершаться с ошибкой для учетных записей без подтвержденной почты.

Это необходимо для соответствия требованиям DMCA. Если вы не заметили предупреждений об этом, которые cargo писал в последних выпусках, зайдите в crates.io/me для указания и подтверждения вашей почты. Данный почтовый адрес никогда не будет опубликован и будет использован исключительно для непосредственного функционала crates.io.

Разработчики 1.33.0

Множество людей совместно создавало Rust 1.33. Мы не смогли бы завершить работу без участия каждого из вас. Спасибо!

Митап Parity Technologes в Москве 16 декабря

Mon, 10 Dec 2018 00:00:00 +0000

Всем привет!

В грядущее воскресенье (16 декабря) Parity Technologes организует митап в Москве, приуроченный к конференции RustRush

От команды Parity на RustRush приезжает с десяток человек; на митапе Пьер Кригер (@tomaka) будет рассказывать про rust-libp2p, а Джек Френшем (@Vurich) — про Parity Substrate. Доклады будут на английском, но мы поможем с переводом, если вам будет проще формулировать вопросы по-русски.

Митап пройдёт в помещении коворкинга “Ключ Трёхгорка” по адресу: Рочдельская 15, стр. 17–18, 3 этаж (ближайшее метро - “Улица 1095 года”). Начало — в 18:00.

Вход бесплатный, но надо заранее зарегистрироваться на странице митапа, чтобы мы знали на сколько человек готовить зал и заказывать еду и напитки.

Записывайтесь и приходите!

Выпуск Rust 1.31 и Rust 2018

Thu, 06 Dec 2018 00:00:00 +0000

Команда разработчиков Rust рада сообщить о выпуске новой версии Rust, 1.31.0, а также “Rust 2018”. Rust - это язык программирования, который дает возможность каждому создавать надежное и эффективное программное обеспечение.

Если у вас установлена предыдущая версия Rust с помощью rustup, то для обновления Rust до версии 1.31.0 вам достаточно выполнить:

1	$ rustup update stable

Если у вас еще не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта. С подробными примечаниями к выпуску Rust 1.31.0 можно ознакомиться на GitHub.

Что вошло в стабильную версию 1.31.0

Rust 1.31, возможно, самый значительный выпуск со времен Rust 1.0! В данный выпуск включена первая итерация «Rust 2018», но это не единственное нововведение! Обзор улучшений будет длинный, поэтому вот оглавление:

Что вошло в стабильную версию 1.31.0
Разработчики 1.31.0

Rust 2018

Мы писали о Rust 2018 впервые в марте, и затем в июле. За подробностями зачем нужен Rust 2018, обратитесь к этим публикациям. В данном обзоре нам и так много что нужно рассказать, поэтому мы сосредоточимся только на том, что такое Rust 2018. Также об этом можно почитать в посте на Mozilla Hacks (перевод).

Вкратце, Rust 2018 - это возможность объединить в связное целое всю работу, которую мы проделали за последние три года. Rust 2018 - это нечто большее, чем просто набор улучшений языка. В дополнении к ним, он включает:

Инструментарий (поддержка в IDE, rustfmt, Clippy)
Документацию
Работу предметных рабочих групп
Новый веб-сайт

Дальше мы расскажем обо всем этом подробнее и о других нововведениях.

Давайте создадим новый проект с помощью Cargo:

$ cargo new foo

Вот содержимое Cargo.toml:

[package]
name = "foo"
version = "0.1.0"
authors = ["Your Name <you@example.com>"]
edition = "2018"

[dependencies]

В секцию [package] был добавлен новый ключ: edition. Обратите внимание, что он установлен в 2018. Вы также можете установить его в 2015 - это значение будет установлено по умолчанию, если ключ отсутствует.

С использованием Rust 2018 будут разблокированы некоторые новые возможности, которые не разрешены в Rust 2015.

Важно отметить, что каждый пакет может быть в режиме 2015 или 2018, и они будут работать вместе. Ваш проект 2018 редакции может использовать зависимости 2015 редакции, а проект 2015 редакции может использовать зависимости 2018 редакции. Это гарантирует целостность экосистемы и что все новые возможности будут опциональны, сохраняя совместимость с существующим кодом. Кроме того, когда вы решите перенести код Rust 2015 на Rust 2018, изменения могут быть внесены автоматически через cargo fix.

Вы можете спросить: а что с самими новыми возможностями? Во-первых, они добавляются также и в Rust 2015, если оказываются совместимы с особенностями этой редакции. Таким образом, большая часть языка остается одинаковой везде. Вы можете посмотреть руководство по редакциям, чтобы узнать минимальную версию rustc для каждой новой возможности и другие ее требования. Однако, есть несколько больших нововведений, о которых нужно упомянуть отдельно: нелексические времена жизни и некоторые изменения в системе модулей.

Нелексические времена жизни

Если вы следили за развитием Rust последние несколько лет, то вы могли время от времени встречать термин “NLL” или “нелексические времена жизни” (“non-lexical lifetimes”). Это - жаргонизм, который, если говорить простыми словами, означает: анализатор заимствований стал умнее и теперь принимает некоторый корректный код, который до этого отклонял. Рассмотрим пример:

fn main() {
    let mut x = 5;

    let y = &x;

    let z = &mut x;
}

Раньше Rust выдавал ошибку компиляции:

error[E0502]: cannot borrow `x` as mutable because it is also borrowed as immutable
 --> src/main.rs:5:18
  |
4 |     let y = &x;
  |              - immutable borrow occurs here
5 |     
6 |     let z = &mut x;
  |                  ^ mutable borrow occurs here
7 | }
  | - immutable borrow ends here

Это потому, что область жизни ссылок определялась “лексически”; то есть, заимствование y считалось активным, пока y не выйдет из области видимости в конце main, даже если мы никогда больше не используем y внутри области. С кодом выше все в порядке, но анализатор зависимостей не мог этого понять.

Теперь этот код замечательно компилируется.

Но что, если бы мы использовали y? Например так:

fn main() {
    let mut x = 5;
    let y = &x;
    let z = &mut x;
    
    println!("y: {}", y);
}

Раньше Rust выдавал вам такую ошибку:

error[E0502]: cannot borrow `x` as mutable because it is also borrowed as immutable
 --> src/main.rs:5:18
  |
4 |     let y = &x;
  |              - immutable borrow occurs here
5 |     let z = &mut x;
  |                  ^ mutable borrow occurs here
...
8 | }
  | - immutable borrow ends here

В Rust 2018 это сообщение об ошибке улучшилось:

error[E0502]: cannot borrow `x` as mutable because it is also borrowed as immutable
 --> src/main.rs:5:13
  |
4 |     let y = &x;
  |             -- immutable borrow occurs here
5 |     let z = &mut x;
  |             ^^^^^^ mutable borrow occurs here
6 |     
7 |     println!("y: {}", y);
  |                       - borrow later used here

Вместо того, чтобы указывать, где y выходит из области видимости, оно показывает, где происходит конфликтное заимствование. Это значительно упрощает отладку ошибок такого рода.

В Rust 1.31 это улучшение исключительно для Rust 2018. Мы планируем добавить его в Rust 2015 позже.

Изменения системы модулей

Система модулей может вызывать затруднения у людей, впервые изучающих Rust. Конечно, всегда есть что-то, для освоения чего требуется время. Но главная причина того, почему модули так смущают многих - несмотря на простые и последовательные правила, определяющие систему модулей, последствия их применения могут казаться противоречивыми, загадочными и противоестественными.

Поэтому редакция 2018 вносит некоторые изменения в то, как работают пути, упрощая систему модулей и делая ее понятнее.

Вот краткое резюме:

extern crate больше не требуется практически нигде.
Вы можете импортировать макросы с помощью use, вместо использования атрибута #[macro_use].
Абсолютные пути начинаются с имени контейнера, где ключевое слово crate относится к текущему контейнеру.
foo.rs и поддиректория foo/ могут сосуществовать; mod.rs больше не требуется при размещении подмодулей в поддиректории.

Это выглядит как произвольный набор правил, но в целом ментальная модель теперь значительно упростилась.

Тут еще много деталей, пожалуйста, обратитесь к руководству по редакциям за выяснением всех подробностей.

Дополнительные правила вывода времен жизни

Давайте поговорим об улучшении, доступном в обоих редакциях: мы добавили некоторые дополнительные правила вывода для блоков impl и определений функций. Код вроде такого:

impl<'a> Reader for BufReader<'a> {
    // здесь методы
}

может быть теперь записан так:

impl Reader for BufReader<'_> {
    // здесь методы
}

Время жизни '_ по-прежнему показывает, что BufReader принимает его как параметр, но нам больше не нужно задавать для него имя.

Времена жизни все еще требуется определять в структурах. Однако нам больше не нужно писать столько шаблонного кода, как раньше:

// Rust 2015
struct Ref<'a, T: 'a> {
    field: &'a T
}

// Rust 2018
struct Ref<'a, T> {
    field: &'a T
}

Зависимость : 'a будет выведена. Вы все еще можете указать ее явно, если хотите. Мы рассматриваем и другие возможности для вывода в подобных местах на будущее, но пока не имеем конкретных планов.

`const fn`

В Rust есть несколько способов объявления функции: fn для обычных функций, unsafe fn для небезопасных функций и extern fn для внешних функций. В этом выпуске добавлен новый способ объявления функции: const fn. Он используется так:

const fn foo(x: i32) -> i32 {
    x + 1
}

Константная функция может вызываться как обычная функция, но помимо этого она может использоваться в любом константном контексте. При этом она выполнится во время компиляции, а не во время выполнения программы. Например:

const SIX: i32 = foo(5);

Функция foo выполнится во время компиляции и SIX примет значение 6.

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

Использовать целочисленные арифметические операции и операции сравнения
Использовать любые логические операции, кроме && и ||
Конструировать массивы, структуры, перечисления и кортежи
Вызывать другие константные функции
Обращаться по индексу в массивах и срезах
Обращаться к полям структур и кортежей
Использовать константы (но не статические значения, и даже не ссылки на них)
Использовать & и * ссылки
Приводить типы, исключая приведение сырого указателя к целочисленному значению

Мы будем расширять возможности константных функций, но приведенного выше набора уже достаточно, чтобы использовать const fn на практике.

Подробности смотрите в справочнике.

Новые инструменты

Редакция 2018 знаменует начало нового уровня зрелости экосистемы инструментов Rust. Cargo, Rustdoc и Rustup были основными инструментами, начиная с версии 1.0; с редакцией 2018 приходит новое поколение инструментов, которыми теперь все могут пользоваться: Clippy, Rustfmt и поддержка IDE.

Статический анализатор кода clippy теперь доступен в стабильном Rust. Вы можете установить его через rustup component add clippy и запустить командой cargo clippy. Clippy теперь получил версию 1.0 и имеет такие же гарантии стабильности статических проверок, что и rustc. Новые проверки могут добавляться, или может расширяться функционал старых, но старые не могут быть удалены (могут быть только помечены как устаревшие). Это означает, что код, который компилируется с clippy, будет продолжать компилироваться с clippy (при условии, что для проверок не задано генерировать ошибку через deny), но может выдавать новые предупреждения.

Rustfmt - это инструмент для форматирования кода в Rust. Автоматическое форматирование кода позволит вам сэкономить время, кроме того, оно приблизит ваш код к официальному стилю Rust. Вы можете установить его через rustup component add rustfmt и использовать командой cargo fmt.

Текущий выпуск включает Rustfmt 1.0. Отныне мы гарантируем обратную совместимость для Rustfmt: если вы отформатируете свой код сегодня, то форматирование не изменится в будущем (только для параметров по умолчанию). Обратная совместимость означает, что теперь практично запускать Rustfmt на вашем CI (используйте cargo fmt --check). Попробуйте это вместе с “форматированием при сохранении” в редакторе, и ваш рабочий процесс революционизируется.

Поддержка IDE - одна из самых востребованных возможностей инструментов для Rust. Сейчас имеется несколько решений высокого качества:

Работа по поддержке в IDE не закончена. В частности, автодополнение кода в редакторах, основанных на RLS, не на высоте. Однако, если вы в основном хотите поддержку типов, документации и “перехода к определению”, то вы останетесь довольны.

Инструментальные проверки качества кода (tool lints)

В Rust 1.30 мы стабилизировали “инструментальные атрибуты”, такие как #[rustfmt::skip]. В Rust 1.31 мы стабилизировали нечто подобное: “инструментальные проверки качества кода” (“tool lints”), такие как #[allow(clippy::bool_comparison)]. Это позволяет задавать пространства имен для проверок, чтобы стало понятнее, из каких инструментов они берутся.

Если вы ранее использовали проверки Clippy, вы можете выполнить миграцию следующим образом:

// было
#![cfg_attr(feature = "cargo-clippy", allow(bool_comparison))]

// стало
#![allow(clippy::bool_comparison)]

Вам больше не нужен cfg_attr! Вам также теперь будут выдаваться предупреждения, которые помогут перейти на использование нового стиля.

Документация

В Rustdoc было несколько улучшений в этом году, и была выпущена полностью переписанная книга “The Rust Programming Language”. Вы можете купить бумажную копию от No Starch Press!

Раньше ее называли “вторым изданием” книги, но, так как она стала первым печатным изданием, то это вызвало путаницу. Ведь и печатное издание планируется периодически обновлять. В конце концов, после множества дискуссий с No Starch, было решено обновлять книгу на веб-сайте вместе с каждым выпуском, а No Starch будет периодически забирать изменения и печатать их. Книга довольно хорошо продается и собирает деньги для Black Girls Code.

Вы можете найти новую версию книги здесь.

Предметные рабочие группы

В этом году мы объявили о создании четырех рабочих групп:

Сетевые сервисы
Приложения командной строки
WebAssembly
Встроенные устройства

Группы очень усердно работали, чтобы сделать Rust лучше в каждой из этих областей. Вот некоторые достижения:

В сетевых сервисах переработали интерфейс для Futures, а сверх этого еще и async/await. Эти улучшения еще не выпущены, но мы уже близки к этому!
Команда CLI работала над библиотеками и документацией, чтобы сделать приложения командной строки лучше.
Группа WebAssembly выпустила множество инструментов мирового уровня для использования Rust с wasm.
Для встроенных устройств появилась возможность вести разработку ARM на стабильном Rust!

Обо всем этом подробнее можно узнать на нашем новом сайте!

Новый веб-сайт

На прошлой неделе мы анонсировали новую версию нашего веб-сайта. Теперь она стала официальной версией rust-lang.org!

Для ее создания потребовался год работы многих людей. И хотя до полного завершения еще многое нужно сделать, мы гордимся проделанной работой.

Стабилизация стандартной библиотеки

Были добавлены новые реализации From:

u8 теперь реализует From<NonZeroU8>, аналогично и для других числовых типов и их NonZero эквивалентов
Option<&T> реализует From<&Option<T>>, аналогично и для &mut

Также были стабилизированы следующие функции:

slice::align_to и его мутабельный аналог
slice::chunks_exact, а также его мутабельный и r аналоги (такие как slice::rchunks_exact_mut) во всех комбинациях

Подробности смотрите в примечаниях к выпуску.

Улучшения в Cargo

Cargo теперь будет загружать пакеты параллельно, используя HTTP/2.

Кроме того, так как extern crate указывать теперь не обязательно, было бы неприятно писать extern crate foo as bar; для переименования зависимости. Поэтому вы можете делать это в Cargo.toml таким образом:

[dependencies]
baz = { version = "0.1", package = "foo" }

или, что эквивалентно:

[dependencies.baz]
version = "0.1"
package = "foo"

Теперь пакет foo доступен как baz для использования в вашем коде.

Подробности смотрите в примечаниях к выпуску.

Разработчики 1.31.0

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

Конференция RustRush 15-16 декабря в Москве

Fri, 09 Nov 2018 00:00:00 +0000

Всем привет!

15-16 декабря в Москве пройдёт первая международная конференция по Rust в России, RustRush 2018!

Это двухдневная конференция с докладами и воркшопами.

До 19 ноября открыт приём докладов. Подать доклад.

Билеты уже в продаже. Для участников сообщества доступен промо-код RUSTYCRATE со скидкой 20% на обычные билеты. Купить билет.

Участникам конференции доступен блок номер в отеле конференции — Novotel Moscow City. Как забронировать — читайте дальше.

Если вашей компании интересно мероприятие, свяжитесь с нами по почте sponsor@rustrush.ru. Мы предлагаем групповые билеты, помощь в продвижении ваших продуктов, помощь в поиске разработчиков на Rust.

Докладчики

К нам приедут 4 докладчика из Rust Project: Стив Клабник, Эшли Уильямс, Паскаль Хертлиф, Катарина Фей. Все докладчики.

Доклады

На данный момент анонсировано 2 доклада. Полная программа.

Подход Rust: как делать вещи правильно. Паскаль Хертлиф

Паскаль - ведущий рабочей группы CLI в проекте Rust. Он - автор и участник многих крейтов. Также Паскаль - соорганизатор митапа Rust Кёльн.

Этот доклад - про то, как Rust не изобретает ничего нового. Сам Rust - думаете, это какое-то изобретение? Нет. Он позаимствовал (игра слов) многое из таких языков, как Cyclone и ATS, и это задало тон для всего сообщества. Не руководствуйтесь правилом “Not Invented Here”. Лучше возьмите что-то из другой экосистемы, что-то академическое, какую-то хорошую, но неудобную библиотеку, доработайте их для массового применения всеми - и вы в шоколаде!

История async и его будущее. Катарина Фей

Катарина активно пишет на Rust с 2017 и является автором многих крейтов. Она - участник рабочей группы CLI, а её основная область ответственности - эргономика разработчиков.

Асинхронное сетевое программирование вызывает большой интерес. И сообщество Rust - не исключение. Хорошая поддержка асинхронности важна, особенно учитывая растущую популярность языка в разработке сетевых приложений и распределённых систем. Это было целью рабочей группы Networking для Rust 2018. И хотя не все цели для выпуска в конце года были достигнуты, были сделаны существенные изменения и в основе синтаксиса, и в экосистеме. В этом докладе мы рассмотрим и уже сделанные вещи, и то, что ещё только запланировано.

Блок номеров для участников

Доступны Улучшенные номера с одной кроватью или двумя отдельными кроватями. Забронировать можно по почте H7149-RE@ACCOR.COM, сообщив следующие данные:

Даты бронирования
ФИО
Номер телефона
Email
Промокод: RUSTYCRATE

Заключение

Подпишитесь на нас в социальных сетях или по email:

Facebook, Twitter, VK.

Выпуск Rust 1.30

Thu, 25 Oct 2018 00:00:00 +0000

Команда разработчиков Rust рада сообщить о выпуске новой версии Rust: 1.30.0. Rust - это системный язык программирования, нацеленный на безопасность, скорость и параллельное выполнение кода.

Если у вас установлена предыдущая версия Rust с помощью rustup, то для обновления Rust до версии 1.30.0 вам достаточно выполнить:

1	$ rustup update stable

Если у вас еще не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта. С подробными примечаниями к выпуску Rust 1.30.0 можно ознакомиться на GitHub.

Что вошло в стабильную версию 1.30.0

Rust 1.30 - выдающийся выпуск с рядом важных нововведений. Но уже в понедельник в официальном блоге будет опубликована просьба проверить бета-версию Rust 1.31, которая станет первым релизом “Rust 2018”. Дополнительную информацию об этом вы найдете в нашей предыдущей публикации “What is Rust 2018”.

Процедурные макросы

Еще в Rust 1.15 мы добавили возможность определять “пользовательские derive-макросы”. Например, с помощью serde_derive, вы можете объявить:

#[derive(Serialize, Deserialize, Debug)]
struct Pet {
    name: String,
}

И конвертировать Pet в JSON и обратно в структуру, используя serde_json. Это возможно благодаря автоматическому выводу типажей Serialize и Deserialize с помощью процедурных макросов в serde_derive.

Rust 1.30 расширяет функционал процедурных макросов, добавляя возможность определять еще два других типа макросов: “атрибутные процедурные макросы” и “функциональные процедурные макросы”.

Атрибутные макросы подобны derive-макросам для автоматического вывода, но вместо генерации кода только для атрибута #[derive], они позволяют пользователям создавать собственные новые атрибуты. Это делает их более гибкими: derive-макросы работают только для структур и перечислений, но атрибуты могут применяться и к другим объектам, таким как функции. Например, атрибутные макросы позволят вам при использовании веб-фреймворка делать следующее:

#[route(GET, "/")]
fn index() {

Этот атрибут #[route] будет определен в самом фреймворке как процедурный макрос. Его сигнатура будет выглядеть так:

#[proc_macro_attribute]
pub fn route(attr: TokenStream, item: TokenStream) -> TokenStream {

Здесь у нас имеется два входных параметра типа TokenStream: первый - для содержимого самого атрибута, то есть это параметры GET, "/". Второй - это тело того объекта, к которому применен атрибут. В нашем случае - это fn index() {} и остальная часть тела функции.

Функциональные макросы определяют такие макросы, использование которых выглядит как вызов функции. Например, макрос sql!:

let sql = sql!(SELECT * FROM posts WHERE id=1);

Этот макрос внутри себя будет разбирать SQL-выражения и проверять их на синтаксическую корректность. Подобный макрос должен быть объявлен следующим образом:

#[proc_macro]
pub fn sql(input: TokenStream) -> TokenStream {

Это похоже на сигнатуру derive-макроса: мы получаем токены, которые находятся внутри скобок, и возвращаем сгенерированный по ним код.

Макросы и `use`

Теперь можно импортировать макросы в область видимости с помощью ключевого слова use. Например, для использования макроса json из пакета serde-json, раньше использовалась запись:

#[macro_use]
extern crate serde_json;

let john = json!({
    "name": "John Doe",
    "age": 43,
    "phones": [
        "+44 1234567",
        "+44 2345678"
    ]
});

А теперь вы должны будете написать:

extern crate serde_json;

use serde_json::json;

let john = json!({
    "name": "John Doe",
    "age": 43,
    "phones": [
        "+44 1234567",
        "+44 2345678"
    ]
});

Здесь макрос импортируется также, как и другие элементы, так что нет необходимости в использовании аннотации macro_use.

Наконец, стабилизирован пакет proc_macro, который дает API, необходимый для написания процедурных макросов. В нем также значительно улучшили API для обработки ошибок, и такие пакеты, как syn и quote уже используют его. Например, раньше:

#[derive(Serialize)]
struct Demo {
    ok: String,
    bad: std::thread::Thread,
}

приводило к такой ошибке:

error[E0277]: the trait bound `std::thread::Thread: _IMPL_SERIALIZE_FOR_Demo::_serde::Serialize` is not satisfied
 --> src/main.rs:3:10
  |
3 | #[derive(Serialize)]
  |          ^^^^^^^^^ the trait `_IMPL_SERIALIZE_FOR_Demo::_serde::Serialize` is not implemented for `std::thread::Thread`

Теперь же будет выдано:

error[E0277]: the trait bound `std::thread::Thread: serde::Serialize` is not satisfied
 --> src/main.rs:7:5
  |
7 |     bad: std::thread::Thread,
  |     ^^^ the trait `serde::Serialize` is not implemented for `std::thread::Thread`

Улучшение системы модулей

Система модулей долгое время становилась больным местом для новичков в Rust’е; некоторые из ее правил оказывались неудобными на практике. Настоящие изменения являются первым шагом, который мы предпринимаем на пути упрощения системы модулей.

В дополнении к вышеупомянутому изменению для макросов, есть два новых улучшения в использовании use. Во-первых, внешние пакеты теперь добавляются в prelude, то есть:

// было
let json = ::serde_json::from_str("...");

// стало
let json = serde_json::from_str("...");

Подвох в том, что старый стиль не всегда был нужен из-за особенностей работы системы модулей Rust:

extern crate serde_json;

fn main() {
    // это прекрасно работает; мы находимся в корне пакета, поэтому `serde_json`
    // здесь в области видимости
    let json = serde_json::from_str("...");
}

mod foo {
    fn bar() {
        // это не работает; мы внутри пространства имен `foo`, и `serde_json`
        // здесь не объявлен
        let json = serde_json::from_str("...");

    }

    // одно решение - это импортировать его внутрь модуля с помощью `use`
    use serde_json;

    fn baz() {
        // другое решение - это использовать `::serde_json`, когда указывается
        // абсолютный путь, вместо относительного
        let json = ::serde_json::from_str("...");
    }
}

Было неприятно получать сломанный код, просто перемещая функцию в подмодуль. Теперь же будет проверяться первая часть пути, и если она соответствует некоторому extern crate, то он будет использоваться независимо от положения вызова в иерархии модулей.

Наконец, use стал поддерживать импорт элементов в текущую область видимости с путями, которые начинаются на crate:

mod foo {
    pub fn bar() {
        // ...
    }
}

// было
use ::foo::bar;
// или
use foo::bar;

// стало
use crate::foo::bar;

Ключевое слово crate в начале пути указывает, что путь будет начинаться от корня пакета. Раньше пути, указанные в строке импорта use, всегда указывались относительно корня пакета, но пути в остальном коде, напрямую ссылающиеся на элементы, указывались относительно текущего модуля, что приводило к противоречивому поведению путей:

mod foo {
    pub fn bar() {
        // ...
    }
}

mod baz {
    pub fn qux() {
        // было
        ::foo::bar();
        // не работает, в отличии от `use`:
        // foo::bar();

        // стало
        crate::foo::bar();
    }
}

Как только новый стиль станет широко использоваться, то он, мы надеемся, сделает абсолютные пути более ясными, без необходимости использовать уродливый префикс ::.

Все эти изменения в совокупности упрощают понимание того, как разрешаются пути. В любом месте, где вы видите путь a::b::c, кроме оператора use, вы можете спросить:

Является ли a именем пакета? Тогда нужно искать b::c внутри него.
Является ли a ключевым словом crate? Тогда нужно искать b::c от корня текущего пакета.
В противном случае, нужно искать a::b::c от текущего положения в иерархии модулей.

Старое поведение путей в use, всегда начинающихся от корня пакета, по-прежнему применимо. Но при единовременном переходе на новый стиль, данные правила будут применяться к путям повсюду единообразно, и вам придется гораздо меньше заботиться об импортах при перемещении кода.

Сырые идентификаторы

Вы можете теперь использовать ключевые слова как идентификаторы, используя следующий новый синтаксис:

// определение локальной переменной с именем `for`
let r#for = true;

// определение функции с именем `for`
fn r#for() {
    // ...
}

// вызов той функции 
r#for();

Пока не так много случаев, когда вам это пригодится. Но однажды вы попытаетесь использовать пакет для Rust 2015 в проекте для Rust 2018 или наоборот, тогда набор ключевых слов у них будет разным. Мы расскажем об этом подробнее в предстоящем анонсе Rust 2018.

Приложения без стандартной библиотеки

Еще в Rust 1.6 мы объявили о стабилизации no_std и libcore для создания проектов без стандартной библиотеки. Однако, с одним уточнением: можно было создавать только библиотеки, но не приложения.

В Rust 1.30 можно использовать атрибут #[panic_handler] для самостоятельной реализации паники. Это означает, что теперь можно создавать приложения, а не только библиотеки, которые не используют стандартную библиотеку.

Другое

И последнее: в макросах теперь можно сопоставлять модификаторы области видимости, такие как pub, с помощью спецификатора vis. Дополнительно, “инструментальные атрибуты”, такие как #[rustfmt::skip], теперь стабилизированы. Правда для использования с инструментами статического анализа, наподобие #[allow(clippy::something)], они еще не стабильны.

Подробности смотрите в примечаниях к выпуску.

Стабилизация стандартной библиотеки

В этом выпуске были стабилизированы следующие API:

Ipv4Addr::{BROADCAST, LOCALHOST, UNSPECIFIED}
Ipv6Addr::{BROADCAST, LOCALHOST, UNSPECIFIED}
Iterator::find_map

Кроме того, стандартная библиотека уже давно имеет функции для удаления пробелов с одной стороны некоторого текста, такие как trim_left. Однако, для RTL-языков значение “справа” и “слева” тут приводят к путанице. Поэтому мы вводим новые имена для этих функций:

trim_left -> trim_start
trim_right -> trim_end
trim_left_matches -> trim_start_matches
trim_right_matches -> trim_end_matches

Мы планируем объявить устаревшими старые имена (но не удалить, конечно) в Rust 1.33.

Подробности смотрите в примечаниях к выпуску.

Улучшения в Cargo

Самое большое улучшение Cargo в этом выпуске заключается в том, что теперь у нас есть индикатор выполнения!

Подробности смотрите в примечаниях к выпуску.

Разработчики 1.30.0

Множество людей совместно создавало Rust 1.30. Мы не смогли бы завершить работу без участия каждого из вас. Спасибо!

Выпуск Rust 1.29

Thu, 13 Sep 2018 00:00:00 +0000

Команда разработчиков Rust рада сообщить о выпуске новой версии Rust: 1.29.0. Rust - это системный язык программирования, нацеленный на безопасность, скорость и параллельное выполнение кода.

Если у вас установлена предыдущая версия Rust с помощью Rustup, то для обновления Rust до версии 1.29.0 вам достаточно выполнить:

1	$ rustup update stable

Если у вас еще не установлен Rustup, вы можете установить его с соответствующей страницы нашего веб-сайта. С подробными примечаниями к выпуску Rust 1.29.0 можно ознакомиться на GitHub.

Что вошло в стабильную версию 1.29.0

1.29 привносит не очень много изменений. Ожидается что Rust 1.30 и 1.31 будут очень значительными, так что большая часть 1.29 итерации ушла на подготовку к будущим изменениям. Два самых заметных нововведения этого выпуска даже не касаются самого языка: это две новые возможности Cargo и обе они связаны с предупреждениями.

cargo fix автоматически исправляет предупреждения в коде
cargo clippy - статический анализатор Rust кода, помогающий поймать распространенные ошибки и просто улучшить код

`cargo fix`

С выпуском Rust 1.29 у Cargo появляется новая подкоманда: cargo fix. Если вы когда-либо писали на Rust, то скорее всего уже сталкивались с предупреждениями компилятора. Например, рассмотрим такой код:

fn do_something() {}

fn main() {
    for i in 0..100 {
        do_something();
    }
}

В нем мы вызываем do_something сто раз, но никогда не используем переменную i. Rust предупреждает нас об этом:

> cargo build
   Compiling myprogram v0.1.0 (file:///path/to/myprogram)
warning: unused variable: `i`
 --> src\main.rs:4:9
  |
4 |     for i in 1..100 {
  |         ^ help: consider using `_i` instead
  |
  = note: #[warn(unused_variables)] on by default

    Finished dev [unoptimized + debuginfo] target(s) in 0.50s

Видите подсказку о переименовании в _i? Мы можем автоматически применить ее при помощи cargo fix:

> cargo fix
    Checking myprogram v0.1.0 (file:///C:/Users/steve/tmp/fix)
      Fixing src\main.rs (1 fix)
    Finished dev [unoptimized + debuginfo] target(s) in 0.59s

Если теперь мы откроем src\main.rs, то увидим исправленный код:

fn do_something() {}

fn main() {
    for _i in 0..100 {
        do_something();
    }
}

Теперь в коде используется _i, и предупреждение больше не выдается.

Первая версия cargo fix исправляет далеко не все предупреждения. Для своей работы cargo fix использует специальный API компилятора, который предлагает исправлять только те предупреждения, в которых мы абсолютно уверены. Со временем их список будет расширяться.

`cargo clippy`

Еще о предупреждениях: теперь вы можете попробовать cargo-clippy через Rustup. Clippy это статический анализатор, который выполняет много дополнительных проверок вашего кода.

Например:

let mut lock_guard = mutex.lock();

std::mem::drop(&lock_guard)

operation_that_requires_mutex_to_be_unlocked();

Синтаксически это правильный код, но мы можем получить дедлок, потому что вызвали drop для ссылки на lock_guard, а не для самого lock_guard. Вызов drop для ссылки имеет мало смысла и почти наверняка является ошибкой.

Установим предварительную версию Clippy через Rustup:

1	$ rustup component add clippy-preview

и запустим ее:

$ cargo clippy
error: calls to `std::mem::drop` with a reference instead of an owned value. Dropping a reference does nothing.
 --> src\main.rs:5:5
  |
5 |     std::mem::drop(&lock_guard);
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: #[deny(drop_ref)] on by default
note: argument has type &std::result::Result<std::sync::MutexGuard<'_, i32>, std::sync::PoisonError<std::sync::MutexGuard<'_, i32>>>
 --> src\main.rs:5:20
  |
5 |     std::mem::drop(&lock_guard);
  |                    ^^^^^^^^^^^
  = help: for further information visit https://rust-lang-nursery.github.io/rust-clippy/v0.0.212/index.html#drop_ref

Как видно из примечания к сообщению, вы можете получить полный список всех возможных предупреждений по ссылке.

Обратите внимание, что это только ознакомительная версия; Clippy еще не достиг 1.0, поэтому набор и поведение проверок еще могут меняться. Мы выпустим компонент clippy, как только он будет стабилизирован, а пока просим вас посмотреть на деле предварительную версию и рассказать нам о своем опыте.

Да, есть еще нюанс: к сожалению, пока что нельзя использовать clippy вместе с cargo-fix. Работа над этим ведется.

Подробности смотрите в примечаниях к выпуску.

Стабилизация стандартной библиотеки

В этом выпуске были стабилизированы следующие API:

Также теперь вы можете сравнивать &str и OsString.

Подробности смотрите в примечаниях к выпуску.

Улучшения в Cargo

Выше мы уже описали две новые подкоманды Cargo. Также Cargo теперь будет автоматически пытаться починить Cargo.lock файлы, испорченные git mergeом. Это поведение можно отключить флагом --locked.

cargo doc обзавелся новым флагом: --document-private-items. По умолчанию, cargo doc документирует только публичные части API, потому что предназначен для генерации пользовательской документации. Но если вы работаете над своим пакетом и в нем есть внутренняя документация, то --document-private-items включит генерацию документации вообще для всего.

Подробности смотрите в примечаниях к выпуску.

Разработчики 1.29.0

Множество людей участвовало в разработке Rust 1.29. Мы не смогли бы завершить работу без участия каждого из вас. Спасибо!

Выпуск Rust 1.28

Thu, 02 Aug 2018 00:00:00 +0000

Команда разработчиков Rust рада сообщить о выпуске новой версии Rust: 1.28.0. Rust - это системный язык программирования, нацеленный на безопасность, скорость и параллельное выполнение кода.

Если у вас установлена предыдущая версия Rust с помощью rustup, то для обновления Rust до версии 1.28.0 вам достаточно выполнить:

1	$ rustup update stable

Если у вас еще не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта. С подробными примечаниями к выпуску Rust 1.28.0 можно ознакомиться на GitHub.

Что вошло в стабильную версию 1.28.0

Глобальные аллокаторы

С помощью аллокаторов программы на Rust получают память во время выполнения. Раньше Rust не позволял изменять способ распределения памяти, что ограничивало его использование в некоторых случаях. На одних платформах использовался jemalloc, на других - системный аллокатор, но пользователи не могли это контролировать. В выпуске 1.28.0 стабилизирован атрибут #[global_allocator], который позволяет программам на Rust выбирать системный аллокатор, а также определять новые аллокаторы, реализуя типаж GlobalAlloc.

Аллокатор по умолчанию для Rust-программ на некоторых платформах - это jemalloc. Стандартная библиотека теперь предоставляет дескриптор системного аллокатора, который можно использовать для переключения на использование системного аллокатора, когда это необходимо, путем статического объявления с атрибутом #[global_allocator].

use std::alloc::System;

#[global_allocator]
static GLOBAL: System = System;

fn main() {
    let mut v = Vec::new();
    // Память будет выделяться системным аллокатором.
    v.push(1);
}

Однако, иногда вам требуется определить собственный аллокатор для специфической функциональной области вашего приложения. Это тоже относительно легко сделать, реализовав типаж GlobalAlloc. Подробнее о том, как это сделать, вы можете прочитать в документации.

Улучшено сообщение об ошибке форматирования

Работа по улучшению диагностики продолжается, на этот раз с акцентом на форматирование:

format!("{_foo}", _foo = 6usize);

Раньше сообщение об ошибке в этом месте было довольно скудным:

error: invalid format string: expected `'}'`, found `'_'`
  |
2 |     format!("{_foo}", _foo = 6usize);
  |             ^^^^^^^^

Теперь новое диагностическое сообщение указывает конкретную причину, по которой строка формата недействительна:

error: invalid format string: invalid argument name `_foo`
  |
2 |     let _ = format!("{_foo}", _foo = 6usize);
  |                       ^^^^ invalid argument name in format string
  |
  = note: argument names cannot start with an underscore

Подробности смотрите в примечаниях к выпуску.

Стабилизация стандартной библиотеки

Кроме уже упомянутой стабилизации типажа GlobalAlloc, в этом выпуске стабилизированы NonZero числовые типы. Это типы-обертки вокруг стандартных беззнаковых целочисленных типов: NonZeroU8, NonZeroU16, NonZeroU32, NonZeroU64, NonZeroU128 и NonZeroUsize.

Они позволяют оптимизировать размер хранящихся данных. Например, Option<u8> занимает два байта, тогда как Option<NonZeroU8> - один. Обратите внимание, что эта оптимизация сохраняется даже тогда, когда NonZeroU8 завернут внутрь другой структуры; в примере ниже показано, что Door по-прежнему занимает один байт, даже когда он помещен внутрь Option. Эта оптимизация применима также и к перечислениям, определенным пользователем, Option тут не является особенным.

use std::mem;
use std::num::NonZeroU8;

struct Key(NonZeroU8);

struct Door {
    key: Key,
}

fn main() {
    assert_eq!(mem::size_of::<Door>(), 1);
    assert_eq!(mem::size_of::<Option<Door>>(), 1);
}

Также было стабилизировано множество других компонентов библиотеки, полный список которых вы найдете в подробных примечаниях к выпуску.

Улучшения в Cargo

Cargo теперь не позволит вам публиковать пакеты со скриптами сборки, которые модифицируют каталог src. Каталог src в пакете следует считать неизменяемым.

Разработчики 1.28.0

Множество людей участвовало в разработке Rust 1.28. Мы не смогли бы завершить работу без участия каждого из вас. Спасибо!

Выпуск Rust 1.27

Thu, 21 Jun 2018 00:00:00 +0000

Команда разработчиков Rust рада сообщить о выпуске новой версии Rust: 1.27.0. Rust - это системный язык программирования, нацеленный на безопасность, скорость и параллельное выполнение кода.

Если у вас установлена предыдущая версия Rust с помощью rustup, то для обновления Rust до версии 1.27.0 вам достаточно выполнить:

1	$ rustup update stable

Если у вас еще не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта. С подробными примечаниями к выпуску Rust 1.27.0 можно ознакомиться на GitHub.

Также мы хотим обратить ваше внимание вот на что: перед выпуском версии 1.27.0 мы обнаружили ошибку в улучшении сопоставлений match, введенном в версии 1.26.0, которая может привести к некорректному поведению. Поскольку она была обнаружена очень поздно, уже в процессе выпуска данной версии, хотя присутствует с версии 1.26.0, мы решили не нарушать заведенный порядок и подготовить исправленную версию 1.27.1, которая выйдет в ближайшее время. И дополнительно, если потребуется, версию 1.26.3. Подробности вы сможете узнать из соответствующих примечаний к выпуску.

Что вошло в стабильную версию 1.27.0

В этом выпуске выходят два больших и долгожданных улучшения языка. Но сначала небольшой комментарий относительно документации: во всех книгах в библиотечке Rust теперь доступен поиск! Например, так можно найти “заимствование” (“borrow”) в книге “Язык программирования Rust” Надеемся, это облегчит поиск нужной вам информации. Кроме того, появилась новая Книга о rustc. В этой книге объясняется, как напрямую использовать rustc, а также как получить другую полезную информацию, такую как список всех статических проверок.

SIMD

Итак, теперь о важном: отныне в Rust доступны базовые возможности использования SIMD! SIMD означает “одиночный поток команд, множественный поток данных” (single instruction, multiple data). Рассмотрим функцию:

pub fn foo(a: &[u8], b: &[u8], c: &mut [u8]) {
    for ((a, b), c) in a.iter().zip(b).zip(c) {
        *c = *a + *b;
    }
}

Здесь мы берем два целочисленных среза, суммируем их элементы и помещаем результат в третий срез. Приведенный выше код демонстрирует самый простой способ сделать это: нужно пройтись по всему набору элементов, сложить их вместе и сохранить результат. Однако, компиляторы зачастую находят решение получше. LLVM часто “автоматически векторизует” подобный код, где такая затейливая формулировка означает просто “использует SIMD”. Представьте, что срезы a и b имеют длину в 16 элементов оба. Каждый элемент - это u8, а значит срезы будут содержать по 128 бит данных каждый. Используя SIMD, мы можем разместить оба среза a и b в 128-битных регистрах, сложить их вместе одной инструкцией и затем скопировать результирующие 128 бит в c. Это будет работать намного быстрее!

Несмотря на то, что стабильная версия Rust всегда была в состоянии использовать преимущества автоматической векторизации, иногда компилятор просто недостаточно умен, чтобы понять, что можно ее применить в данном случае. Кроме того, не все CPU поддерживают такие возможности. Поэтому LLVM не может использовать их всегда, так как ваша программа может работать на самых разных аппаратных платформах. Поэтому в Rust 1.27, с добавлением модуля std::arch, стало возможно использовать эти виды инструкций напрямую, то есть теперь мы не обязаны полагаться только на интеллектуальную компиляцию. Дополнительно у нас появилась возможность выбирать конкретную реализацию в зависимости от различных критериев. Например:

#[cfg(all(any(target_arch = "x86", target_arch = "x86_64"),
      target_feature = "avx2"))]
fn foo() {
    #[cfg(target_arch = "x86")]
    use std::arch::x86::_mm256_add_epi64;
    #[cfg(target_arch = "x86_64")]
    use std::arch::x86_64::_mm256_add_epi64;

    unsafe {
        _mm256_add_epi64(...);
    }
}

Здесь мы используем флаги cfg для выбора правильной версии кода в зависимости от целевой платформы: на x86 будет использоваться своя версия, а на x86_64 - своя. Мы также можем выбирать и во время выполнения:

fn foo() {
    #[cfg(any(target_arch = "x86", target_arch = "x86_64"))]
    {
        if is_x86_feature_detected!("avx2") {
            return unsafe { foo_avx2() };
        }
    }

    foo_fallback();
}

Здесь у нас имеется две версии функции: одна использует AVX2 - специфический вид SIMD, который позволяет выполнять 256-битные операции. Макрос is_x86_feature_detected! сгенерирует код, который проверит, поддерживает ли процессор AVX2, и если да, то будет вызвана функция foo_avx2. Если нет, то мы прибегнем к реализации без AVX, foo_fallback. Значит наш код будет работать очень быстро на процессорах, поддерживающих AVX2, но также будет работать и на остальных процессорах, хотя и медленнее.

Все это выглядит слегка низкоуровневым и неудобным - да, так и есть! std::arch - это именно примитивы для такого рода вещей. Мы надеемся, что в будущем мы все-таки стабилизируем модуль std::simd с высокоуровневыми возможностями. Но появление базовых возможностей работы с SIMD позволяет теперь экспериментировать с высокоуровневой поддержкой различным библиотекам. Например, посмотрите пакет faster. Вот фрагмент кода без SIMD:

let lots_of_3s = (&[-123.456f32; 128][..]).iter()
    .map(|v| {
        9.0 * v.abs().sqrt().sqrt().recip().ceil().sqrt() - 4.0 - 2.0
    })
    .collect::<Vec<f32>>();

Для использования SIMD в этом коде с помощью faster, вам потребуется изменить его так:

let lots_of_3s = (&[-123.456f32; 128][..]).simd_iter()
    .simd_map(f32s(0.0), |v| {
        f32s(9.0) * v.abs().sqrt().rsqrt().ceil().sqrt() - f32s(4.0) - f32s(2.0)
    })
    .scalar_collect();

Он выглядит почти таким же: simd_iter вместо iter, simd_map вместо map, f32s(2.0) вместо 2.0. Но в итоге вы получаете SIMD-версию вашего кода.

Помимо этого, вы можете никогда не писать такое сами, но, как всегда, это могут делать библиотеки, от которых вы зависите. Например, в пакет regex уже добавили поддержку, и его новая версия будет иметь SIMD-ускорение без необходимости вам вообще что-либо делать!

`dyn Trait`

В конечном итоге мы пожалели о выбранном изначально синтаксисе типажей-объектов в Rust. Как вы помните, для типажа Foo можно так определить типаж-объект:

Box<Foo>

Однако, если Foo - была бы структура, это означало бы просто размещение структуры внутри Box<T>. При разработке языка мы думали, что такое сходство будет хорошей идеей, но опыт показал, что это приводит к путанице. И дело не только в Box<Trait>: impl SomeTrait for SomeOtherTrait также является формально корректным синтаксисом, но вам почти всегда требуется написать impl<T> SomeTrait for T where T: SomeOtherTrait вместо этого. То же самое и с impl SomeTrait, который выглядит так, будто добавляет методы или возможную реализацию по умолчанию в типаж, но на самом деле он добавляет собственные методы в типаж-объект. Наконец, по сравнению с недавно добавленным синтаксисом impl Trait, синтаксис Trait выглядит короче и предпочтительней к использованию, но на самом деле это не всегда верно.

Поэтому в Rust 1.27 мы стабилизировали новый синтаксис dyn Trait. Типажи-объекты теперь выглядят так:

// было => стало
Box<Foo> => Box<dyn Foo>
&Foo => &dyn Foo
&mut Foo => &mut dyn Foo

Аналогично и для других типов-указателей: Arc<Foo> теперь Arc<dyn Foo> и т.д. Из-за требования обратной совместимости мы не можем удалить старый синтаксис, но мы добавили статическую проверку bare-trait-object, которая по умолчанию разрешает старый синтаксис. Если вы хотите запретить его, то вы можете активировать данную проверку. Мы подумали, что с проверкой, включенной по умолчанию, сейчас будет выводиться слишком много предупреждений.

Кстати, мы работаем над инструментом под названием rustfix, который сможет автоматически обновлять ваш код до более новых идиом. Он будет использовать подобные статические проверки для этого. Следите за сообщениями о rustfix в будущих анонсах.

`#[must_use]` для функций

В заключении, было расширено действие атрибута #[must_use]: теперь он может использоваться для функций.

Раньше он применялся только к типам, таким как Result <T, E>. Но теперь вы можете делать так:

#[must_use]
fn double(x: i32) -> i32 {
    2 * x
}

fn main() {
    double(4); // warning: unused return value of `double` which must be used

    let _ = double(4); // (no warning)
}

С этим атрибутом мы также слегка улучшили стандартную библиотеку: Clone::clone, Iterator::collect и ToOwned::to_owned будут выдавать предупреждения, если вы не используете их возвращаемые значения, что поможет вам заметить дорогостоящие операции, результат которых вы случайно игнорируете.

Подробности смотрите в примечаниях к выпуску.

Стабилизация библиотек

В этом выпуске были стабилизированы следующие новые API:

Подробности смотрите в примечаниях к выпуску.

Улучшения в Cargo

В этом выпуске Cargo получил два небольших улучшения. Во-первых, появился новый флаг --target-dir, который можно использовать для изменения целевой директории выполнения.

Дополнительно, доработан подход Cargo к тому, как обрабатывать цели. Cargo пытается обнаружить тесты, примеры и исполняемые файлы в рамках вашего проекта. Однако иногда требуется явная конфигурация. Но в первоначальной реализации это сделать было проблематично. Скажем, у вас есть два примера, и Cargo их оба обнаруживает. Вы хотите сконфигурировать один из них, для чего добавляете [[example]] в Cargo.toml, чтобы указать параметры примера. В настоящее время Cargo увидит, что вы определили пример явно, и поэтому не будет пытаться делать автоматическое определение других. Это слегка огорчает.

Поэтому мы добавили несколько ‘auto’-ключей в Cargo.toml. Мы не можем исправить такое поведение без возможной поломки проектов, которые по неосторожности на него полагались. Поэтому если вы хотите сконфигурировать некоторые цели, но не все, вы можете установить ключ autoexamples в true в секции [package].

Подробности смотрите в примечаниях к выпуску.

Разработчики 1.27.0

Множество людей участвовало в разработке Rust 1.27. Мы не смогли бы завершить работу без участия каждого из вас.

Спасибо!

rustycrate.ru

Выпуск Rust 1.34.0

Что вошло в стабильную версию 1.34.0

Альтернативные cargo реестры

? в документационных тестах

Поддержка произвольного потока токенов в пользовательских атрибутах

TryFrom и TryInto

fn before_exec устарела в пользу unsafe fn pre_exec

Стабилизация в библиотеках

Шаблон индексирования для нового типа

Проблема

Трюк с новым типом (Newtype)

Последовательность

Больше impls

Выпуск Rust 1.33.0

Что вошло в стабильную версию 1.33.0

Расширение возможностей const fn

Pin API

Импортировать как _

Стабилизация стандартной библиотеки

Улучшения в Cargo

Crates.io

Разработчики 1.33.0

Митап Parity Technologes в Москве 16 декабря

Выпуск Rust 1.31 и Rust 2018

Что вошло в стабильную версию 1.31.0

Rust 2018

Нелексические времена жизни

Изменения системы модулей

Дополнительные правила вывода времен жизни

const fn

Новые инструменты

Инструментальные проверки качества кода (tool lints)

Документация

Предметные рабочие группы

Новый веб-сайт

Стабилизация стандартной библиотеки

Улучшения в Cargo

Разработчики 1.31.0

Конференция RustRush 15-16 декабря в Москве

Докладчики

Доклады

Подход Rust: как делать вещи правильно. Паскаль Хертлиф

История async и его будущее. Катарина Фей

Блок номеров для участников

Заключение

Выпуск Rust 1.30

Что вошло в стабильную версию 1.30.0

Процедурные макросы

Макросы и use

Улучшение системы модулей

Сырые идентификаторы

Приложения без стандартной библиотеки

Другое

Стабилизация стандартной библиотеки

Улучшения в Cargo

Разработчики 1.30.0

Выпуск Rust 1.29

Что вошло в стабильную версию 1.29.0

cargo fix

cargo clippy

Стабилизация стандартной библиотеки

Улучшения в Cargo

Разработчики 1.29.0

Выпуск Rust 1.28

Что вошло в стабильную версию 1.28.0

Глобальные аллокаторы

Улучшено сообщение об ошибке форматирования

Стабилизация стандартной библиотеки

Улучшения в Cargo

Разработчики 1.28.0

Выпуск Rust 1.27

Что вошло в стабильную версию 1.27.0

SIMD

dyn Trait

#[must_use] для функций

Стабилизация библиотек

Улучшения в Cargo

Разработчики 1.27.0

Альтернативные `cargo` реестры

`?` в документационных тестах

`TryFrom` и `TryInto`

`fn before_exec` устарела в пользу `unsafe fn pre_exec`

Расширение возможностей `const fn`

Импортировать как `_`

`const fn`

Макросы и `use`

`cargo fix`

`cargo clippy`

`dyn Trait`

`#[must_use]` для функций