Rust порада, яка вам точно не треба ⤵️

Якщо ви часто використовуєте Windows API, можливо Owned тип із windows::core модуля це саме те, чого вам не вистачало.
Дуже легко забути закрити (вивільнити) handle. Якщо ви обгорнете його Owned типом, то він автоматично закриється під час видалення об'єкта (on drop).

use windows::Win32::System::Services::SC_HANDLE;
use windows::code::Owned;

pub struct MyService {
    service_handle: Owned<SC_HANDLE>,
}

MyService {
    service_handle: unsafe { Owned::new(OpenSCManagerW(/* ... */)?) },
}

Owned тип можна використовувати із кожним типом із windows крейту, який імплементує Free трейт. По-суті, це будь який handle.

Сьогодні ми поговоримо про інтеграційні тести 😁

Згідно Rust book (The Rust Programming Language/Test Organization#integration-tests), інтеграційні тести мають бути у tests папці, де кожен файл компілюється як окремий крейт.

Проте ми усе ще можемо скомпілювати усі інтеграційні тести як один крейт. Потрібно додати main.rs та оголосити у ньому усі інші модулі. Наприклад (джерело):

tests/
  cargosuite/
    main.rs # <- mod build; mod run; mod test; mod publish;
    build.rs
    run.rs
    test.rs
    publish.rs

Тепер усі інтеграцій тести буду скомпільовані як один бінарний крейт.

Чому нам взагалі хотіти компілювати інтеграційні тести як один крейт? Відповідь: продуктивність та час виконання (джерело).
1. Маючи один крейт на усі інтеграційні тести ми зменшуємо час компіляції. Таким чином rustc потрібно проводити менше лінкування (оскільки маємо менше крейтів). Побачити порівняння продуктивності виконання тестів можна на самому cargo: https://github.com/rust-lang/cargo/pull/5022#issuecomment-364691154.
2. cargo виконуватиме всі тести з одного бінарного крейту паралельно. У той час як бінарні крейти запускаються послідовно. Тобто чим менше бінарних крейтів, тим більше паралельності під час виконання тестів.

Бонус ⭐️
Якщо ви хочете компілювати інтеграційні тести як окремі крейти, але при цьому виділити спільний код у підмодулі щоб перевикористати у тестах, то ви це можете зробити помістивши потрібний код у окрему директорію. Детальніше про це можна прочитати тут:
🔘 The Rust Programming Language/Test Organization#submodules-in-integration-tests.
🟣 matklad/Delete Cargo Integration Tests.

Сьогодні поговоримо про цікавий спосіб пришвидшити компіляцію Rust проекту у 1.5 – 2.5 разів 😁

На цей пост надихнув пост Інгвара у Bluesky ➡️ https://bsky.app/profile/rreverser.com/post/3lhtsq7revk2c

Трохи історії. У листопаді 2023 року робоча група Parallel Rustc (The Parallel Rustc Working Group) анонсували використання Cranelift як альтернативного бекенду компілятора для когодегенерації та можливості паралелізму у фронтенді компілятора: Faster compilation with the parallel front-end in nightly. Спочатку планувалося зробити його доступним у стабільному Rust у 2024, але, як ми бачимо, не склалося.

Ну і власне уся суть пришвидшення в увімкненні Cranelift 😁 Для цього потрібно зробити 2 речі:
1. Встановити:

rustup update nightly
rustup component add rustc-codegen-cranelift --toolchain nightly

2. Конфігурувати:

# .cargo/config.toml
[build]
rustflags = ["-Z", "threads=8"]

[unstable]
codegen-backend = true

# you can customize profiles
[profile.dev]
codegen-backend = "cranelift"

Тепер при компіляції проекту через cargo +nightly build використовуватиметься Cranelift замість LLVM.

Недоліки:
🔴 Використання нестабільної версії Rust. Тому ми рекомендуємо використовувати це тільки для debug компіляцій, а для релізів брати тільки стабільну версію Rust.
🔴 Cranelift може генерувати трохи повільніший код ніж LLVM. Зазвичай для debug білдів це не страшно, але варто мати на увазі.

Корисні посилання:
🟡 Faster compilation with the parallel front-end in nightly.
🟣 github/rust-lang/rustc_codegen_cranelift.
🔘 doc.rust-lang.org/nightly/cargo/reference/unstable#codegen-backend.
🔘 doc.rust-lang.org/cargo/reference/profiles.