Rust

The Rust project announced today the release of Rust 1.91 as the latest update to this popular programming language priding itself on memory safety capabilities.

Most notable with Rust 1.91 is now promoting aarch64-pc-windows-msvc to a Tier-1 platform status. This takes the Windows on ARM support by the Rust programming language to the highest support tier inline with other common operating systems and architectures. Rust 1.91 with Tier-1 for Windows on 64-bit ARM/AArch64 also means pre-built binaries are also available for new releases.

Finally. What was a weekly update took them this time 2 months. The long anticipated Next generation trait solver, that replaces the previous Chalk. Alongside of ton of fixes and changes. Below I just copy the New Features list.

• Commit: 049767e
• Release: 2025-10-27 (v0.3.2658)

New Features

• (first contribution) parse script frontmatter.
• (first contribution) expose addConfiguration API from the Code extension.
• switch from Chalk to the next trait solver.
• support navigation on primitives.
• add all, any and not completions in #[cfg].
• log flycheck stdout and stderr to files.
• add "Generate blanket trait impl" assist.
• add "Flip range expression" assist.
• add "Remove else branches" assist.
• improve fixture support.

Fixes

...

Internal Improvements

...

Typst 0.14 was released. Bringing super cool new features and fixes to typst.

Typst is getting an even better alternative to latex.

Universal graphical transforms, better async python integration, unified text layout, and more.

Going public today is CVE-2025-62518, or better known by the name given by the security researchers involved: TARmageddon. The TARmageddon vulnerability affects the popular async-tar Rust library and its various forks like tokio-tar. In turn TARmageddon impacts the uv Python package manager and other users of this library.

Edera made public today their discovery of a critical boundary-parsing bug in the async-tar Rust library and downstream forks like tokio-tar. TARmageddon is rated as a "high" severity bug and can lead to remote code execution through file overwriting attacks.

I'm happy to have finally fixed the issue we had with LTO (link-time optimization) and with cross-language LTO!

https://crates.io/search?q=fnmatch

https://crates.io/crates/fnmatch-regex at version v0.2.1, repository: https://gitlab.com/ppentchev/fnmatch-regex-rs

https://crates.io/crates/fnmatch-regex2 at version v0.4.0, repository: https://gitlab.com/brmmm3/fnmatch-regex2-rs (DO NOT SIGN IN, UNTIL WE KNOW ITS SAFE)

I was looking through some crates and noticed there is "fnmatch-regex2", just below "fnmatch-regex". The second one is newer; 4 months ago updated, compared to the original 12 months ago updated. And it has more recent downloads and a "higher version number".

My first thought was, this either adds new functionality, or the old one is abandoned maybe? Looking in readme and documentation, I could not find anything that describes the differences. Looking at the source code on Gitlab, the first crate just shows it normally to me, but the second wants me to log in. My alarm glocks go on. Even the changelog for both are identical at version 0.2.1 (the original crate 1) without any word about changes, but the crate repository shows it should be at version v0.4.0.

I would like to know what you guys think about it. I can't even audit the code right now, even if its the same Gitlab instance on gitlab.com. Should this be reported? Or am I just paranoid?

EDIT:

After asking in Discord, someone said I can view the source code in Docs.rs: https://docs.rs/crate/fnmatch-regex2/0.4.0/source/ . This is much better, but I am still cautious. I still don't know what the actual changes are and would need to dive into the code and compare to find out. Which is not really something I expect to do from a trustful library.

Hey all, I've been contemplating what approach I should take in my app, think along the lines of mapping with lots of UI elements but also a 2D portal/window for showing the map etc.

I want it to be cross platform so thought I'd go with Egui and look at implementing the "game" parts to that. But as I thought more about it, maybe it would be more beneficial to use Bevy and rely on its UI framework.

Thoughts? Maybe Bevy would be easier, but might be too much of a hit on performance because its not a game that I'm making. Egui might be more difficult to add the game stuff, but more performant and not running a full game engine.

I'm really conflicted. It would be good to be able to turn off/disable the game part of it to reduce load if it isn't needed at the time

I'm impressed with how many great tools have been created in a short period of time. The Rust community really pulled together and made sure that there are Rust alternatives to as many tools out there as possible.

Thank you so much, and keep up with great work!

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @thisweekinrust.bsky.social on Bluesky or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR.

Want TWIR in your inbox? Subscribe here.