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

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.

There was recently this article about Linus Torvalds' issues with rustfmt, which prompted others to voice their agreement with his sentiment online.

Yesterday someone pointed out how rustfmt is effectively unmaintained with basically no activity on the repository for months.

The contributors graph shows a similar story - there is essentially no development happening on rustfmt, it seems.

Awful Rustdocs is a CLI tool that generates or improves Rustdoc comments by harvesting symbols via rust_ast.nu, enriching each item with ast-grep context (callers, intra-body calls, qualified paths), and prompting your LLM to produce concise, high-quality docs.

You don't need hundreds of prompts and agents if you're smart about your context.

I'm running it on all my Rust projects right now using the Systems Programming Qwen 3 4B finetune I created, and it saves me an incredible amount of time by creating docs that are almost always good enough to publish straight off but act more as a draft for me. It cuts down on a lot of repetitive typing and lets me get back to doing what I love (writing code).

It requires Nushell, but you should probably already be using that, and if this is how you find out about Nushell, then even better, make the jump; it's worth it.