fn with_order<'o>(order: &'o Order) -> impl (for<'a> Fn(&'a str) -> (impl Iterator<Item = usize> + 'a + 'o)) + 'o

Real Rust code written by real programmers

(which doesn't actually work)

А для того, чтобы оно всё-таки работало, нужно, чтобы реализовали impl Fn() -> impl Trait in return position (привет, Вафель) и, желательно, синтаксис для явного написания замыкания с полиморфизмом высшего ранга.

И то, кстати, не факт, что сработает, поскольку в силу того, что возвращаемое замыкание содержит &'o Order, это замыкание, вообще говоря, должно принимать ссылку на строковой слайс не с произвольным временем жизни, а живущую не менее, чем 'o, а ограничение на времена жизни в higher-ranked trait bounds не работают даже для fn pointers.

#prog #tips

Не используйте для подписи коммитов на Github GPG-ключи, у которых указан e-mail, но не имя — Github почему-то считает, что к этим ключам не прикреплены e-mail (The email in this signature doesn’t match the committer email) и потому отказывается верифицировать коммиты, подписанные этим ключом.

#prog #rust #rustreleasenotes

Вышла версия Rust 1.60.0!

(да, да, я в курсе, что это было неделю назад)

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

▪️Помните, инкрементальную компиляцию отключили по умолчанию, потому что она была сломана? Так вот, её починили и включили обратно.
(анекдот-про-козу.txt)

▪️В этот раз изменений в самом языке совсем мало — они в основном в библиотеке и тулинге — но те, что есть, достаточно важны для писателей библиотек. Теперь возможно делать условную компиляцию по стратегии реализации паники и по наличию на целевой платформе атомиков конкретного размера — последнее, вероятно, связано, связано с усилиями в рамках проекта Rust for Linux. Писать корректный и переносимый код стало немного проще — и, кстати, первое изменение теперь позволяет сделать ошибку компиляции для кода, который полагается на то, что паника реализовывается через раскрутку стека, для обеспечения корректности (да, substrate, я смотрю на тебя).

▪️Важное изменение касательно cargo-манифестов. До нынешней версии наличие опциональной зависимости автоматически создавало feature с таким же именем. Это временами не очень удобно, поскольку вызывает конфликты имён из глобального пространства имён крейтов с локальным пространством имён для фичей. Более того, использование фичи из зависимости автоматически подключало эту зависимость, что несколько уменьшало весь смысл её возможной опциональности.

Чтобы покончить с этим безобразием, Cargo.toml теперь поддерживает два новых синтаксиса для списка фичей (вместе с новой семантикой, разумеется). Первый — это префикс dep:. Его использование означает подключение зависимости для данной фичи без создания одноимённой фичи для крейта. Второй — это суффикс ? для имени зависимости. Строка dependency?/feature_name означает, что используется фича feature_name из dependency — но только в том случае, если эта зависимость реально используется.

Вот пример из официального блогопоста:

[dependencies]
serde = { version = "1.0.133", optional = true }
rgb = { version = "0.8.25", optional = true }

[features]
serde = ["dep:serde", "rgb?/serde"]

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

▪️Компилятор теперь по умолчанию использует полный формат трассировки стека при паниках, если он не задан явно. Дебажить ошибки в компиляторе (особенно гейзенбаги) стало немного проще.

▪️Стабилизировали abs_diff для примитивных численных типов. Наконец-то, джва года ждал.

▪️Instant больше не использует хаки для обеспечения монотонности на платформах, на которых декларируемо монотонные часы не являются таковыми. Это позволяет избавиться от оверхеда на синхронизацию на таких платформах. Взамен теперь методы, которые ранее паниковали на underflow, вместо этого используют насыщающее поведение (т. е. заменяют отрицательную разницу на ноль). Да, это означает, что некоторые ошибки в логике программы теперь будут проходить незамеченными. Instant::checked_duration_since к вашим услугам.

▪️Помните, я рассказывал про ненужные автовыводимые ограничения? Так вот, эти соображения применили к BuildHasherDefault, iter::Empty и future::Pending. Чуть меньше мусора в обобщённом коде, ура.

▪️Стабилизировали Vec::spare_capacity_mut, который возвращает неинициализированную часть ёмкости вектора в виде &mut [MaybeUninit<T>]. (А вот Vec::split_at_spare_mut — нет, так что наполнить вектор данными, исходя из уже инициализированных данных, нельзя)

▪️Вы когда-нибудь хотели сделать значение со счётчиком ссылок, которое держит слабую ссылку на себя? Не знаю, зачем вам это нужно, но теперь это можно сделать через конструктор Rc::new_cyclic (и Arc::new_cyclic, разумеется)

На этом всё, как я уже говорил, полный список изменений в RELEASES.md.

И вдогонку... Вы знали, что не-никогда — это никогда?

Вы спросите, откуда я это знаю? А дело в том, что я при просмотре последних release notes к Rust 1.60.0 я обнаружил, что в документации к инструментам для расчёта покрытия кода (то, о чём я не упомянул в своём обзоре) есть место, где есть подпись к скриншоту, но нету самого скриншота. Взгляд на коммиты и структуру репы пролил свет на недоразумение: документацию попросту перенесли из unstable book в документацию cargo, при этом забыв исправить относительный путь и перенести сам скриншот.

Я, как добропорядочный программист, решил это дело исправить (и в итоге исправил), но вот дёрнул меня чёрт в процессе выяснить, почему коммиты, который я запушил с локальной версии репы — на своём компьютере — помечаются Github как unverified... Не, я в итоге разобрался, но знание этого сэкономило бы мне полчаса, если не больше, гугления.

#prog #rust #article

How to speed up the Rust compiler in April 2022 — продолжение серии статей от nnethercote. В этот раз Николас взялся, помимо всего прочего, за оптимизацию декларативных макросов — как их парсинг в самом компиляторе, так и сами эти макросы в популярных библиотеках.

Из-за этой статьи я узнал, что макрос quote написан Толяном является декларативным макросом, а не процедурным, да ещё и использует особую технику для парсинга токенов с контекстом, которая эквивалентна по выразительной силе tt-munchers, но, в отличие от них, не является квадратичной (которую Николас, кстати, и задокументировал).

#prog #cpp

Леон

#prog #c #article

So you think you know C?

(thanks @cutwater)

#prog #rust #c #article

Pointers Are Complicated III, or: Pointer-integer casts exposed

Очередная статья от Ральфа о том, какую семантику должны иметь касты между указателями и числами — предложенный вариант должен существенно упростить абстрактную машину Rust (и C, пусть и в меньшей степени).

#prog #go #article

Golang data races to break memory safety

#prog #rust #article

Improved portability and performance 🦀

Выдержки:

* Why?
In short: There's no standard for building C programs. It's a non-portable mess, and a time sink. Cross-compilation of OpenMP was the last straw. Rust/Cargo is much more dependable, and enables me to support more features on more platforms.

* The platonic ideal portable C exists only as a hypothetical construct in the C standard. The C that exists in the real world is whatever Microsoft, Apple, and others have shipped. That C is a mess of vendor-specific toolchains, each with its own way of doing things, missing features, broken headers, and leaky abstractions. Shouting "it's not C's fault, screw <insert vendor name>!" doesn't solve the problem, but switching to Rust does.

* rayon is a substantial library with thread pools, work-stealing queues, parallel iterators, and many generic interfaces. It being smaller than the "compiler-native" OpenMP was a nice surprise too.

* The hash table implementation in Rust's standard library uses a state-of-the art algorithm, and my C didn't. In theory, nothing stopped me from using the same algorithm in C. In practice, lack of a useful standard library, lack of templates/generics, and the dreadful state of C dependency management did.

Корабль в бутылке