LINUX.ORG.RU

Rust 1.29

 ,


3

6

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

Что вошло в стабильную версию 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:

$ 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 включит генерацию документации вообще для всего.

>>> Примечания к выпуску

>>> Подробности



Проверено: jollheef ()
Последнее исправление: tailgunner (всего исправлений: 3)

Ответ на: комментарий от khrundel

Сам выдумал, сам и опроверг.

Это ты выдумал и привёл это как аргумент.

Ещё раз: функция создания проекта присутствует там, где велосипедят свой формат файла проекта.

А Makefile уже стал файлом проекта? Очень часто он вообще генерируется.

В JAVA мейка нет, но ничего нормального взамен тоже нет, поэтому точно так же велосипедят.

Ха ха, сравнил куй с пальцем.

В Расте есть нормальная карга, соответственно создание проекта нафиг никому не сдалось.

Эта ваша Карга - фактически тот же Maven или Gradle, но со своим форматом конфигурации и структурой директорий проекта.

Я ничего не говорил о том, является ли vscode IDE или нет.

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

На мой вкус, IDE - это...

Не имею никакого желания спорить о вкусах.

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

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

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

У них вовсе не мимоходом.

bbk123 ★★★★★
()
Ответ на: комментарий от ozkriff

Про serde и ripgrep я, допустим, знаю, а вот движуха в сфере игростроения, как мне кажется, узкоспецифичная тема.

Virtuos86 ★★★★★
()
Ответ на: комментарий от Virtuos86

Walton назвал заключительный доклад на RustConf 2018 (о ECS) офигительным, а его суть - «как перестать сражаться с borrow checker»: https://twitter.com/pcwalton/status/1030621092845514753

Хотя, как по мне, докладесса была просто никакая, а суть доклада - какая-то пародия на плод любви MVCC и generational GC: https://www.youtube.com/watch?v=aKLntZcp27M

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 2)
Ответ на: комментарий от tailgunner

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

Virtuos86 ★★★★★
()
Ответ на: комментарий от Virtuos86

Уолтона я тоже не припомню из известных людей из сообщества Rust.

Эх, молодежь. Хоара хоть знаешь? Если уж не Грейдона, то хотя бы Тони?

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от Deleted

Ну про бесплатность ничего не было сказано.
А так ещё можно попробовать KDevelop с соответствующим плагином, но я про его работоспособность ничего сказать не могу.

WatchCat ★★★★★
()
Ответ на: комментарий от ozkriff

Умрет ли crates.io под напором сквотеров без пространств имен пакетов или все идет по плану?

А что ничего сделать не могут? Я просто с трудом представляю подобное в других сообществах. Такие вещи по идее надо пресекать, оставляя право решающего голоса за кем-то, назовем, модератором. Типа «могут удалить на свое усмотрение без объяснения причин», но обычно причины лучше привести для общего блага.

dave ★★★★★
()
Ответ на: комментарий от dave

man npm leftpad

Пока что пакетов очень мало, вот и не заморачиваются.

RazrFalcon ★★★★★
()
Ответ на: комментарий от bbk123

пропиши в любом редакторе пару хоткеев с cargo new и cargo new --bin, будет тебе создание проекта.

anonymous
()
Ответ на: комментарий от dave

А что ничего сделать не могут?

Не хотят:

A more charitable interpretation of crates without code is that people had the intention of creating a library but they haven't gotten it to a state in which they're comfortable releasing it yet. Perhaps life got in the way, or the problem was harder than they thought.

Should these people have their crate names taken away? I am of the opinion that no, they should not. If we agree on that point, then you'd have to be able to distinguish between a well-intentioned reservation of a name and a malicious «landgrab» of a name, and in general the core team has decided to not spend time on monitoring this and making those judgment calls, so that they can work on Rust instead.

I'm sure if there was an egregious, obviously malicious attempt to grab infinite names, or, say, an attempt to harass someone through creating crates or otherwise use names against Rust's code of conduct, you could report it to the core team or moderation team and they would handle it on a case-by-case basis.

^ Комент Кэрол из реддит-срача 2016ого года на эту же тему.

По каким формальным критериям отличить сквоттера от порядочного пользователя? А черт его знает, нужна или сложная система премодерации, или какие-то супер-жесткие правила, или еще что - идей много, но все не без недостатков. За много лет срачей решили что не стоит оно того в общем случае. У администрации crates.io остается право при крайней необходимость передавать владение пакетами и банить совсем уж всем мешающих сквотеров, но не слышал что бы к этому пока прибегали.

Посмотрим, чего из этого в итоге выйдет. :)

ozkriff
() автор топика
Ответ на: комментарий от tailgunner

А чем же измеряется нужность?

Вероятностью что фича понадобится, например. 100 редких мелких косяков могут выбешивать сильнее одного частого большого.

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

Но к чему конкретно относится создание проекта - ХЗ. Я мимикрокодил и теоретик :)

Vit ★★★★★
()

извините, но

что ему надо?

[ebuild     U ~] dev-lang/rust-1.29.1:stable/1.29::gentoo [1.28.0-r1:stable/1.28::gentoo] USE="cargo* jemalloc (-clippy) -debug -doc -libressl -rls -rustfmt -wasm" LLVM_TARGETS="(X86) -AArch64 -AMDGPU -ARM -BPF -Hexagon -Lanai -MSP430 -Mips -NVPTX -PowerPC -Sparc -SystemZ -XCore" 191,463 KiB
[ebuild     U ~] virtual/rust-1.29.1::gentoo [1.28.0::gentoo] 0 KiB
[blocks B      ] dev-util/cargo ("dev-util/cargo" is blocking dev-lang/rust-1.29.1)

Total: 2 packages (2 upgrades), Size of downloads: 191,463 KiB
Conflict: 1 block (1 unsatisfied)

 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (dev-util/cargo-0.29.0:0/0::gentoo, installed) pulled in by
    =dev-util/cargo-0.29.0* required by (virtual/cargo-1.28.0:0/0::gentoo, installed)

  (dev-lang/rust-1.29.1:stable/1.29::gentoo, ebuild scheduled for merge) pulled in by
    =dev-lang/rust-1.29.1* required by (virtual/rust-1.29.1:0/0::gentoo, ebuild scheduled for merge)

до этого было

 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (dev-util/cargo-0.30.0:0/0::gentoo, ebuild scheduled for merge) pulled in by
    >=dev-util/cargo-0.30.0 required by (dev-lang/rust-1.29.1:stable/1.29::gentoo, ebuild scheduled for merge)

  (dev-lang/rust-bin-1.28.0-r1:stable/stable::gentoo, ebuild scheduled for merge) pulled in by
    =dev-lang/rust-bin-1.28.0*[cargo] required by (virtual/cargo-1.28.0:0/0::gentoo, installed)

virtual/rust кривой?

[ebuild   R    ] dev-lang/rust-1.28.0-r1:stable/1.28::gentoo  USE="cargo* jemalloc -debug -doc -libressl -rls -rustfmt -wasm" LLVM_TARGETS="(X86) -AArch64 -AMDGPU -ARM -BPF -Hexagon -Lanai -MSP430 -Mips -NVPTX -PowerPC -Sparc -SystemZ -XCore" 195,370 KiB
[uninstall     ] dev-util/cargo-0.29.0::gentoo  USE="-debug -doc -libressl" 
[blocks b      ] dev-util/cargo ("dev-util/cargo" is blocking dev-lang/rust-1.28.0-r1)

мм да, в общем решено: dev-lang/rust пересобрался с cargo и потом обновился (не через виртуал)

в процессе вот этим прилетело в голову

OSError: [Errno 28] No space left on device

дважды, в ощем, спасибо за апдейт

 * Detected file collision(s):
 * 
 *      /usr/share/zsh/site-functions/_cargo

пришлось ещё

emerge -C dev-util/cargo
emerge -C virtual/cargo

какое-то дерьмо если честно, с каких пор всё так плохо?

anonymous
()
Ответ на: комментарий от mersinvald

юзабелен

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

не стану делать явных утверждений насчет прямоты моих рук although

MyTrooName ★★★★★
()

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

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

ozkriff
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.