Ну а теперь серьёзно.

#prog #rust #rustreleasenotes

Вышла версия Rust 1.71.0! Как обычно, тут только избранные куски, а все изменения в ченджлоге.

▪️Новый вариант опции атрибута #[link] — конкретно kind="raw-dylib" — позволяет на Windows линковаться с динамическими библиотеками, не требуя их наличия во время компиляции. Кросс-компиляция стала немного проще. А, и ещё атрибуты для импорта и экспорта символом из/в DLL, но я недостаточно в этом разбираюсь, чтобы понять разницу.

▪️ Уже имеющиеся варианты ABI обзавелись "*-unwind" вариантами (полный список). Как нетрудно догадаться, паники и исключения, вызывающую раскрутку стека, могут проходить границу между языками. В частности, это означает, что исключения из C++ могут проходить через фреймы Rust-кода, а растовая паника может проходить через фреймы C++-кода. Ловить раскрутку стека, впрочем, можно лишь в фреймах того языка, в котором она была начата.

Это изменение сделает более удобным разработку проектов, смешивающих код на Rust с кодом на других языках. Не *-unwind варианты ABI, как и раньше, абортят процесс, если раскрутка стека пытается пройти по FFI.

▪️Ещё одно изменение, связанное с паниками, но уже исключительно в рамках Rust. Ранее паника во время паники приводила к немедленному аборту процесса. Теперь это ограничение несколько ослабили: паника во время паники не приводит к аборту при условии, что она перехватывается на границе реализации drop. Иными словами, паники внутри деструкторов — которые сами могут быть вызваны из-за паники — могут быть перехвачены и корректно обработаны, не приводя к немедленному прекращению работы.

Но в одном аспекте требования к паникам, наоборот, сделали строже: паника внутри хука на панику сразу ведёт к аборту. В реальном коде это приводило к дедлоку из-за того, что рантайм держал блокировку на глобальный лок для бектрейса.

▪️Стало возможным включать в бинарники скрипты для визуализации значений пользовательских типов в отладчиках. Без этих скриптов в отладчике значение, скажем, Vec<i32> выглядело бы не как последовательность чисел, а как набор из адреса, длины и ёмкости — что, очевидно, не слишком-то полезно. Такими скриптами для визуализации укомплектовывается std. Новый механизм позволяет использовать этот же механизм и пользователям Rust.

▪️Обновлена версия MUSL, используемая для *-linux-musl. Главным образом это означает, что 64-битная версия time_t, позволяющая избежать проблемы 2038 года, используется безусловно для всех систем, включая 32-битные.

▪️Макрос format_args! (на который опираются куча макросов как в std, так и вне её) теперь инлайнит форматируемые значения в форматные строки, если они являются литералами или вложенными format_args!. Если наглядно, то следующие пары вызовов теперь эквивалентны даже не на уровне бинарного кода, а ещё на уровне HIR:

println!("Hello, {}!", "World");
println!("Hello, World!");

println!("[info] {}", format_args!("error"));
println!("[info] error");

println!("[{}] {}", status, format_args!("error: {}", msg));
println!("[{}] error: {}", status, msg);

println!("{} + {} = {}", 1, 2, 1 + 2);
println!("1 + 2 = {}", 1 + 2);

Из того, на что на это влияет:

* в этих случаях в результирующем коде теперь меньше виртуальных вызовов fmt-методов;
* как следствие, макросы вроде log::info! теперь не вредят производительности из-за пробрасывания аргументов через format_args!;
* core::fmt::Arguments::as_str() теперь чаще возвращает Some(_);
* в бинаре теперь может сильно распухнуть секция .text из-за большего количества уникальных строк — особенно, если в коде активно используется макрос dbg!. Не то, чтобы это было большой проблемой, но может выйти боком, если проект компилируется, скажем, под embedded, где каждый байт на счету.

▪️Несколько изменений докатились до стейбла: улучшения расчёта раскладки типов, фикс расчёта приватности для Self-конструктора у кортежных структур, документация для const-инициализации thread local статиков, стабилизация BuildHasher::hash_one.

▪️rustdoc теперь предупреждает о возможно пропущенных бектиках в док-комментах. Но линт для этого нужно включать явно. Пример:

#![warn(rustdoc::unescaped_backticks)]

/// `add(a, b) is the same as `add(b, a)`.
pub fn add(a: i32, b: i32) -> i32 { a + b }

Вывод:

warning: unescaped backtick
 --> src/lib.rs:3:41
  |
3 | /// `add(a, b) is the same as `add(b, a)`.
  |                                         ^
  |
help: a previous inline code might be longer than expected
  |
3 | /// `add(a, b)` is the same as `add(b, a)`.
  |               +
help: if you meant to use a literal backtick, escape it
  |
3 | /// `add(a, b) is the same as `add(b, a)\`.
  |                                         +

▪️cargo new/cargo init внутри воркспейса теперь автоматически подтягивает поля из воркспейса выше.

▪️Гомогенные кортежи и массивы той же длины до 12 элементов включительно теперь можно конвертировать между собой через From/Into.

▪️Очередная пачка API из разряда "стоп, почему такую элементарную вещь стабилизировали только сейчас":

* CStr::is_empty()
* BuildHasher::hash_one
* Пачка методов для обращения знака у NonZero*-типов (во всех вариациях).

▪️read{, _unaligned} на сырых указателях теперь можно использовать в const-контексте — как методы, так и свободные функции в модуле std::ptr. Также в const-контексте теперь можно вызывать split_at (но почему-то всё ещё нельзя split_at_mut :/)

#prog #meme про старые программы

Люблю, когда у меня в руках толстый кошель 🤤

Самая привлекательная вещь в парнях — это их девушки.

Чушь какая-то

Так, причин переезжать в Армению не осталось

#prog #rust #article

Writing a Test Case Generator for a Programming Language

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

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

#prog #meme

А что не так?

(#math?) #meme

Как вызвать лютую зависть всего за восемь слов (фото упомянутого кота выше на канале):

Я два с половиной часа сидел с котом🥰🥰🥰

#prog #article

Swarm Testing

В тестировании софта есть такое направление, как тестирование на случайном входе. Фаззинг — это то, что на слуху, но этим, как правило, называют тестирование на случайных байтах. Это неплохой подход для тестирования парсеров медиаформатов, архивов, сетевых пакетов и прочего в этом духе, но этот подход не особо полезен для тестирования программ с высокоструктурированным входом — например, компиляторов. Для более эффективного тестирования со случайным входом для таких программ требуются генераторы подобного высокоструктурированного входа (вроде Csmith или wasm-smith).

Подобные генераторы, как правило, имеют ручки для настройки того, какие именно элементы будут генерироваться в их выходе. Скажем, Csmith можно указать, генерировать ли операции с указателями или код с объединениями. Среди пользователей таких генераторов распространено мнение, что для наиболее продуктивного использования подобного рода генераторов нужно использовать все возможные подобные фичи для генерации — возможно, настроив при этом их относительный вес, но всё же. Swarm testing же — это другой подход к использованию таких генераторов: вместо того, чтобы прогонять много тестов с одним и тем же набором активированных фич, прогонять тесты пачками, в каждой из которых активированы только часть фич для генерации.

Данный папир показывает результаты эмпирического исследования, которое показывает, что swarm testing — вопреки ожиданиям — ничуть не хуже "традиционного" случайного тестирования, а по некоторым метрикам даже превосходит, и при этом в состоянии дать б‌о‌льший охват багов при меньших затратах процессорного времени. Авторы также спекулируют на тему того, почему swarm testing настолько эффективно.

#prog #rust #article

Back-end parallelism in the Rust compiler

Очередная статья от Nicholas "nnethercote" Nethercote об ускорении компилятора Rust.

LLVM позволяет разбивать LLVM IR, составляющий программу, на несколько кусков — которые называются codegen units (CGU) — и обрабатывать каждый из этих кусков параллельно. Не смотря на то, что, очевидно, это вредит качеству генерируемого кода — так как LLVM не может проводить оптимизации, требующие глобального анализа — на практике это заметно ускоряет компиляцию и потому используется по умолчанию для отладочных билдов.

В этой статье Николас описывает свои попытки ускорить связанную с CGU часть компиляции. Спойлер: большинство попыток ускорить ничего не добились.

#prog #rust #gamedev

Bevy 0.11

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

Во-первых, в Bevy теперь есть были и раньше (thanks @SDesya74 за уточнение) derive-макросы для Deref и DerefMut. Для структур с одним полем они автоматически генерируют реализацию трейтов, которые возвращают ссылку на это поле, а для структур с несколькими полями теперь можно указать атрибут #[deref] над нужным полем:

use bevy_derive::{Deref, DerefMut};

#[derive(Deref, DerefMut)]
struct MyStruct {
value: String,
}

#[derive(Deref, DerefMut)]
struct MyStruct<T> {
#[deref]
value: String,
_phantom: PhantomData<T>,
}

Во-вторых, обновилось API для добавления систем (S из ECS) с учётом ограничений на порядок их применения. Скажем, вот такой код:

app.add_systems(Update, (
(attack, defend).in_set(Combat).before(check_health),
check_health,
(handle_death, respawn).after(check_health)
))

настроит движок так, что системы attack и defend будут запущены в параллель, после них будет запущена check_health, а после неё — handle_death и respawn в параллель. При этом добавили и способ для более краткой записи подобной линейной последовательности:

app.add_systems(Update,
(
(attack, defend).in_set(Combat),
check_health,
(handle_death, respawn)
).chain()
)

Вложенность внутри кортежей систем при этом может быть произвольной, что позволяет весьма коротко описывать богатые графы зависимостей по порядку исполнения. На чуть более абстрактном примере (всё так же из блогопоста):

app.add_systems(Update,
(
(a, (b, c, d).chain()),
(e, f),
).chain()
)

В этом случае в параллель будут запущены системы a и цепочка b -> c -> d, а после окончания их работы будут запущены в параллель системы e и f. Наглядная демонстрация пользы от type-level наворотов.

#prog #rust

Хайлайты из rust-analyzer:

* Добавлена новая команда для отображения раскладки типов в памяти. Выглядит, правда, страшненько. С другой стороны, результат этой команды — это просто HTML со стилями, так что поменять это потом будет не так уж сложно. Кстати, тот факт, что просто HTML достаточно — одно из немногих достоинств основанных на Electron редакторов.
* Добавлена команда, которая по impl-блоку генерирует определение трейта и его реализацию для типа из impl-блока.
* rust-analyzer при наведении на константу показывает во всплывающей подсказке значение этой константы. Теперь по возможности для формирования этой подсказки используется реализация Debug для типа константы. Для, скажем, структур, генерируемых bitflags, это сильно повышает полезность данной подсказки.