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.

Updates from Rust Community

Official

• Announcing Rust 1.97.0
• crates.io: development update

Project/Tooling Updates

• Rewriting Bun in Rust
• Announcing BullMQ for Rust
• prost-protovalidate 0.6 — buf.validate (protovalidate) for prost and buffa: compile-time codegen + runtime CEL, 2872/2872 conformance
• plaza 1.0: a ratatui package-manager TUI that searches pacman, the AUR, apt, dnf, and Flatpak at once
• Danube v0.15.1: native Apache Iceberg integration for streaming-to-lakehouse export
• Guardian Sentinel. The Terminal User Interface for Guardian Decentralized Database - P2P
• kobe 0.33.0: a Rust operator for instant CI Kubernetes clusters
• Elara Mesh: what the black box for AI agents actually does

• kache 0.10.0: instant download dedup, no more polling

• cochlea 0.1.0: a headless, deterministic audio engine for AI agents

Observations/Thoughts

• Open Source Security Podcast: Rust Foundation Maintainers Fund with Lori and Niko
• Moving a Rust WebRTC SFU to thread-per-core
• Faster Rust tests in CI with parallel steps
• [video] The Only Diagram You Need to Understand Rust Ownership
• We compiled our TypeScript parser to WASM
• Understanding the Rust hype for the busy developer
• I red-teamed my own LLM security gateway (Rust) in four passes — every detection gap and how I closed it

Rust Walkthroughs

• [video] Backend Concepts in Rust: HTTP Servers
• Fearless Embedded Rust: A FPV Lego car
• What I learned building a self-corrupting file format in Rust
• Come Async You Are

Miscellaneous

• Oxidize XIAO — An Embedded Rust Community Program

Crate of the Week

This week's crate is dashu, a pure Rust set of libraries of arbitrary precision numbers.

Thanks to JacobZ for the self-suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.

If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs.

Let us know if you would like your feature to be tracked as a part of this list.

Call for Participation; projects and speakers

CFP - Projects

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

• Nika - showcase: CSV → chart PNG → markdown report (nika:chart has no example yet)

If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon!

CFP - Events

Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.

If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon!

Updates from the Rust Project

550 pull requests were merged in the last week

Compiler

• inline some Symbol functions
• predicate/clause cleanups
• remove some AST tokens fields
• resolver: wrap arenas in WorkerLocal
• rework read deduplication with pooled read recorders
• shrink mir::Statement to 40 bytes
• shrink no-op drop elaboration
• specialize common (1, 1) case for arg unification
• use SmallVec for return places in MIR

Library

• add explicit Iterator::count impl for ChunkBy
• allow Allocators to be used as #[global_allocator]s
• fix multiple logic bugs in Arc::make_mut
• implement feature char_to_u32
• make volatile operations const
• move std::io::Write to core::io
• stabilize String::from_utf8_lossy_owned
• stabilize VecDeque::retain_back from truncate_front

Cargo

• install: Move --debug to Compilation options
• source: incorrect duplicate package warning
• fix manifest schema generation: TomlDebugInfo enum-variants doesn't renamed
• dont apply host-config gating to stable behavior
• reduce library search path length in new build dir layout
• reduce rustc -L args used in the new build-dir layout
• rename -Zno-embed-metadata to -Zembed-metadata=no
• test: fix race in cargo_compile_with_invalid_code_in_deps

Clippy

• add new lints: rest_pattern_accessible_field and unnecessary_rest_pattern
• new lint: definition_in_module_root
• arbitrary_source_item_ordering: add configurable trait impl item ordering modes
• tests_outside_test_module: put code in backticks in the lint message
• count length of the first paragraph by its text
• fix suboptimal_flops false negative with ambiguous float literals
• partly disable unneeded_wildcard_pattern when rest_pattern_accessible_field is enabled
• respect the configured MSRV in implicit_saturating_sub's if x != 0 { x -= 1 } rewrite
• trigger single_element_loop if the block contains only a final expression
• optimize nonstandard_macro_braces by 99.9683% (1.1b → 351K)
• perf: bail out of the disallowed_methods rule if the disallowed list is empty

Rust-Analyzer

• ask for disclosure in AI contributions
• add fixes for array length for type_mismatch
• add parens in transformed dyn type in ref type
• avoid panic in merge imports on trailing path separator
• change some things for #[doc = macro!()] expansion
• clamp cttz const-eval result to type width
• correctly handled cfg'ed tail expr, take 2
• crash on code actions when an unresolved module is present
• crash when computing diagnostics with MIR and error types
• don't complete default in default impl
• early late classification of lifetimes
• fix render_const_using_debug_impl constructing outdated std layouts
• fix proc macros TokenStream::from_str() for doc comments
• hide private fields on hover depending on context
• make lsp-server Response type closer aligned to JSON-RPC
• pretty assoc const when trait in macro
• reimplement crate_supports_no_std syntactic heuristic
• resolve non-plain paths in blocks correctly
• support Cargo 1.97.0 lockfile path setting
• hir-ty: walk container exprs for unused_must_use
• fix onEnter erroneously deleting/interpreting $foo
• suggest code action fixes produced from diagnostics under cursor, even if they have effects elsewhere
• treat library files as truly client immutable
• turn BlockLoc into a tracked struct, take 3

Rust Compiler Performance Triage

This week many new optimizations landed, making this a very good week for performance. The only real regression was a fix for a miscompile that will likely be re-landed in the future.

Triage done by @JonathanBrouwer. Revision range: 3659db0d..5503df87

Summary:

2 Regressions, 10 Improvements, 10 Mixed; 7 of them in rollups 36 artifact comparisons made in total

Full report here

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

• Named Fn trait parameters

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

Tracking Issues & PRs

• enable unreachable_cfg_select_predicates lint as part of unused lint group
• Stabilize dyn Allocator
• Tracking Issue for vec_try_remove
• Partially stabilize box_vec_non_null
• Never break between empty parens

• Enable -Zpolonius=next on nightly
• Enable -Znext-solver on nightly by default for testing
• Stabilizing the state of the debuginfo test suite
• Optimize repr(Rust) enums by omitting tags in more cases involving uninhabited variants.
• Proposal for Adapt Stack Protector for Rust

No Items entered Final Comment Period this week for Cargo, Language Reference, Language Team, Leadership Council, Rust RFCs or Unsafe Code Guidelines.

Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.

New and Updated RFCs

• bf16 primitive type

Upcoming Events

Rusty Events between 2026-07-15 - 2026-08-12 🦀

Virtual

• 2026-07-15 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-07-15 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Jiff
• 2026-07-16 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • July, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-07-16 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-07-19 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: Third Sunday
• 2026-07-21 | Virtual (London, UK) | Women in Rust
  • Lunch & Learn: Learning Rust as First Programming Language
• 2026-07-21 | Virtual (Tel Aviv-yafo, IL) | Rust 🦀 TLV
  • שיחה חופשית ווירטואלית על ראסט
• 2026-07-21 | Virtual (Washington, DC, US) | Rust DC
  • Mid-month Rustful
• 2026-07-22 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-07-23 | Mountain View, CA, US | Hacker Dojo
  • RUST MEETUP at HACKER DOJO
• 2026-07-28 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Fourth Tuesday
• 2026-07-29 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-07-30 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-08-02 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: First Sunday
• 2026-08-04 | Virtual (London, GB) | Women in Rust
  • 👋 Community Catch Up
• 2026-08-05 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-08-05 | Virtual (Indianapolis, IN, US) | Indy Rust
  • Indy.rs - with Social Distancing
• 2026-08-11 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Second Tuesday
• 2026-08-12 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-07-19 | Virtual (Bangalore, IN) | Embedded Rust Discord
  • Silicon Sundays

Asia

• 2026-07-18 | Bangalore, IN | Rust Bangalore
  • July 2026 Rustacean Meetup
• 2026-07-19 | Virtual (Bangalore, IN) | Embedded Rust Discord
  • Silicon Sundays
• 2026-07-25 | Mumbai, IN | Rust Mumbai
  • ​Rust Mumbai — July Meetup 🦀
• 2026-07-26 | Pune, MA, IN | Rust Pune
  • Rust Pune: July 2026

Europe

• 2026-07-15 | Dortmund, DE | Rust Dortmund
  • Teach and Hack at Projektspeicher
• 2026-07-21 | Leipzig, DE | Rust - Modern Systems Programming in Leipzig
  • Supercharge Rust funcs with implicit arguments and context-generic programming
• 2026-07-23 | Berlin, DE | Rust Berlin
  • Rust Berlin Talks: The next generation
• 2026-07-23 | London, UK | London Rust Project Group
  • Rama modular service framework for Rust
• 2026-07-23 | London, UK | Rust London User Group
  • LDN Talks: July 2026 Antithesis Takeover
• 2026-07-23 | Paris, FR | Rust Paris
  • Rust meetup #87
• 2026-07-29 | Poland, PL | Rust Poland
  • Rust Poland x Kraków #10
• 2026-07-30 | Manchester, GB | Rust Manchester
  • Rust Manchester July Code Night

North America

• 2026-07-15 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Jiff
• 2026-07-16 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • July, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-07-18 | Boston, MA, US | Boston Rust Meetup
  • North End Rust Lunch, July 18
• 2026-07-21 | San Francisco, CA, US | San Francisco Rust Study Group
  • Rust Hacking in Person
• 2026-07-22 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground
• 2026-07-22 | Los Angeles, CA, US | Rust Los Angeles
  • Rust LA: Rust in Distributed Systems with Flight Science!
• 2026-07-22 | New York, NY, US | Rust NYC
  • Rust NYC: Write A Custom Coding Agent and wasm_zero
• 2026-07-25 | Boston, MA, US | Boston Rust Meetup
  • Porter Square Rust Lunch, July 25
• 2026-07-25 | Brooklyn, NY, US | Flower
  • BOG-A-THON 2
• 2026-07-30 | Atlanta, GA, US | Rust Atlanta
  • Rust-Atl
• 2026-08-01 | Boston, MA, US | Boston Rust Meetup
  • Chinatown Rust Lunch, Aug 1
• 2026-08-04 | Boston, MA, US | Boston Rust Meetup
  • Evening Boston Rust Meetup at Red Hat, Aug 4
• 2026-08-06 | Saint Louis, MO, US | STL Rust
  • Shipping Temporal: How a Global Rust Ecosystem Built Chrome’s Newest Web API

South America

• 2026-08-08 | São Paulo, SP | Rust-SP
  • Rust SP - Aug/2026

Oceania

• 2026-07-21 | Barton, AU | Canberra Rust User Group
  • July Meetup
• 2026-07-23 | Perth, AU | Rust Perth Meetup Group
  • Rust Perth: July Meetup!
• 2026-07-30 | Melbourne, AU | Rust Melbourne
  • Rust Melbourne July 2026

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

Thank you for your PR, but please edit the description like you are a chainsaw-wielding maniac that just discovered the sentences are young adults who came to the lake at summer camp after sunset.

– workingjubilee on Rust github

Thanks to Theemathas for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by:

• nellshamrell
• llogiq
• ericseppanen
• extrawurst
• U007D
• mariannegoldin
• bdillo
• opeolluwa
• bnchi
• KannanPalani57
• tzilist

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

Important

This release applies to self-hosted deployments. Cloud web remains on the previous stable release, and the Cloud Desktop App release is deferred, while the personal-workspace data-loss issue (#6483) is being addressed.

This patch release resolves a Desktop App login loop when signing in to self-hosted instances, adds support for running containers under arbitrary non-root user IDs, and enables response-cookie capture for Agent-routed requests, alongside a lighter JSON response renderer.

What's Changed

• feat: allow containers to run with arbitrary non-root UIDs by @mirarifhasan in #6481
• fix: desktop login loop caused by empty auth cookies by @CuriousCorrelation in #6502
• fix: bump relay for agent response-cookie capture and pin fork revisions by @CuriousCorrelation in #6496
• fix(common): lazy-load jq-wasm in the JSON lens renderer by @hassams in #6463

New Contributors

• @hassams made their first contribution in #6463

Full Changelog: 2026.6.0...2026.6.1

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.

Updates from Rust Community

Project/Tooling Updates

• cuTile Rust - Fearless Concurrency on the GPU, memory-safe, data-race-free GPU kernels, B200 benchmarks
• Iroh 1.0 - Dial Keys, not IPs
• Diplomat - Multi-language FFI for Rust libraries
• I built EVM from scratch. Again.
• processkit 1.0 - async process tree management
• litchee: Rust Lichess API client
• Basin - Numerical Optimization in Rust
• Carboxyl 0.1.0-rc - A servo-based browser for the terminal
• kache 0.6.0 - a shareable Rust + C/C++ build cache
• numax v0.1.0 - first stable release of the numax distributed WASM runtime
• ZamSync - offline-first Rust sync engine
• Ktav - a quote-free config format

Observations/Thoughts

• zlib-rs in Firefox
• Rust Prevents Data Races, Not Race Conditions
• Build your project Zig-style
• How memory safety CVEs differ between Rust and C/C++
• Why stdx is not on crates.io
• [videos] RustWeek 2026 by RustNL, all talks playlist
• The iPad was on Tailscale

Rust Walkthroughs

• Learn Rust Concurrency By Building a Thread Pool
• There Is Life Before Main in Rust
• Async Task Locals From Scratch
• Fearless Embedded Rust: Driving a Lego Car with a Pico W
• Building a provider-agnostic LLM layer in Rust with Rig

Miscellaneous

• [video] RustWeek 2026 talk recordings

Crate of the Week

This week's crate is marser, a parser combinator library with a twist.

Thanks to Arne Code for the self-suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.

If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs.

Let us know if you would like your feature to be tracked as a part of this list.

Call for Participation; projects and speakers

CFP - Projects

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

• solana-infra-doctor - List exit codes in sol-doctor --help
• solana-infra-doctor - Make the invalid-URL error suggest the expected scheme
• solana-infra-doctor - Add a glossary of RPC readiness terms
• openslate - add unit tests for slugify() in api/src/notes.rs
• openslate - add integration tests for notes CRUD in api/src/notes.rs
• openslate - add integration tests for auth flow in api/src/users.rs
• openslate - add unit tests for build_fts_query() in api/src/search.rs
• openslate - add integration tests for auth middleware and logout in api/src/auth.rs
• openslate - add integration tests for media endpoints (DB layer) in api/src/media.rs
• openslate - add unit tests for ext_from_mime() and filename_from_url() in api/src/media.rs

If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon!

CFP - Events

Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.

If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon!

Updates from the Rust Project

527 pull requests were merged in the last week

Compiler

• obligations_for_self_ty: skip irrelevant goals (recompute sub_root from stalled_vars)
• codegen_ssa: peel trans. wrappers on scalable vecs
• add a check for impossible predicates to trivial_const
• add unstable loop unrolling hint attributes
• improve polymorphization of raw pointer formatting
• introduce #[diagnostic::on_type_error(message)]
• perf: reuse green-marking's edge walk when promoting a node

Library

• add or_try_* variants for HashMap and BTreeMap Entry APIs
• make BorrowedBuf and BorrowedCursor generic over the data
• replace printables table with unicode_data.rs tables
• stabilize #![feature(box_as_ptr)]
• stabilize core::range::{legacy, RangeFull, RangeTo}
• stabilize int_format_into feature
• stabilize nonzero_from_str_radix
• stabilize feature float_algebraic

Cargo

• trim-paths: emit CARGO_TRIM_PATHS_REMAP for build.rs
• diag: Give diagnostics the same display path behavior as rustc
• diag: Report all errors, in order
• publish: avoid false deadlock when to_confirm is non-empty
• resolver: move yank policy to resolver layer

Rustdoc

• also run lint unused_doc_comments
• cleanup and (micro-)optimize print_where_clause
• correct doctest span for trailing semicolon after item
• don't strip hidden items in AliasedNonLocalStripper
• some more lazy formatting

Rustfmt

• add doc_comment_code_block_small_heuristics, to override use_small_heuristics in doc code
• stabilize hex_literal_case

Clippy

• new by_ref_peekable_peek lint
• add with_capacity_zero lint
• mem_replace_with_default: also emit inside macros
• infallible_destructuring_match: clean-up, split off the suggestion from the main message
• manual_is_variant_and: lint result.ok().is_some_and(f)
• needless_borrow: same-name methods false positive
• unnecessary_lazy_evaluations: handle closure ->
• deprecate the from_iter_instead_of_collect lint
• remove is_integer_const
• do not trigger ref_patterns lint on automatically derived code
• enhance never loop
• add profile-specific configuration for disallowed methods and types
• fix collapsible_match suggests wrongly when match body has no braces
• fix unnecessary_sort_by reverse suggestion using wrong closure parameter name
• fix redundant closure call async false positive
• perf: check is_in_test last in incompatible_msrv
• perf: check the token kind before extracting source in early literal lints
• perf: match expression shape before MSRV check in cloned_ref_to_slice_refs
• perf: skip doc_markdown text collection and word scan when the lint is allowed
• perf: skip single_component_path_imports module walk when nothing to lint

Rust-Analyzer

• create directory for cargo xtask metrics rustc_tests
• don't count C-variadic ... as a parameter for fn pointers
• support flyimport exclude variants
• fix destructuring assignments not introducing moves
• offer inline macro in macro call and proc macro
• prefer bench command when target is bench to avoid cargo run
• supports inline variable in macro
• use package id as argument to --package if package is not unique
• assist inline_type_alias work on ADT definitions
• perf: defer initial workspace flycheck until cache priming completes
• remove docs about removed analysis-bench command
• remove unnecessary feature flags from tests
• use ASCII lowercase for dylib extensions check

Rust Compiler Performance Triage

This week we had quite a lot of changes, a few small regressions that were a bit tough to diagnose, but the week is largely positive, overall. Notably, we got one massive improvement on the next-solver benchmark in #156187, and a nice speedup for incremental in #157781.

Triage done by @panstromek. Revision range: f3ef3bd8..b5d46ecb

Summary:

1 Regression, 4 Improvements, 8 Mixed; 5 of them in rollups 28 artifact comparisons made in total

Full report here

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

• No RFCs were approved this week.

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

Tracking Issues & PRs

• Fix trait method resolution on an adjusted never type
• Tracking Issue for atomic_from_mut
• stabilize never type
• Lint against iterator functions that panic when N is zero

• Single-byte counter support in coverage instrumentation
• Rename the compiler files containing struct diagnostics to diagnostics.rs

• Delegate Project Grants to the Funding team
• Allocate budget to the Funding team

• Named Fn trait parameters

• Structs with no fields or all-ZST fields are ZSTs

No Items entered Final Comment Period this week for Cargo, Language Team or Unsafe Code Guidelines.

Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.

New and Updated RFCs

• No New or Updated RFCs were created this week.

Upcoming Events

Rusty Events between 2026-06-17 - 2026-07-15 🦀

Virtual

• 2026-06-17 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Rust Study/Hack/Hang-out
• 2026-06-17 | Virtual (Girona, ES) | Rust Girona
  • Weekly coding session
• 2026-06-18 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • June, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-06-18 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-06-21 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: Third Sunday
• 2026-06-23 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Fourth Tuesday
• 2026-06-23 | Virtual (London, UK) | Women in Rust
  • Lunch & Learn: What the heck are monads - and how do we fake them in Rust
• 2026-07-01 | Virtual (Indianapolis, IN, US) | Indy Rust
  • Indy.rs - with Social Distancing
• 2026-07-02 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-07-02 | Virtual (Charlottesville, VA, US) | Charlottesville Rust Meetup
  • Learning Game Development the Hard Way with Rust and Bevy
• 2026-07-02 | Virtual (Nürnberg, DE) | Rust Nuremberg
  • Rust Nürnberg online
• 2026-07-05 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: First Sunday
• 2026-07-07 | Virtual (London, UK) | Women in Rust
  • 👋 Community Catch Up
• 2026-07-14 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Second Tuesday
• 2026-07-15 | Virtual (Vancouver, BC, CA) | Vancouver Rust
  • Jiff

Europe

• 2026-06-18 | Aarhus, DK | Rust Aarhus
  • Talk Night at Danske Commodities
• 2026-06-18 | Edinburgh, GB | Rust and Friends
  • Rust and Friends comes to Glasgow! (daytime coffee)
• 2026-06-18 | Edinburgh, GB | Rust and Friends
  • Rust and Friends comes to Glasgow! (evening pub)
• 2026-06-18 | Barcelona, ES | BcnRust
  • 21st BcnRust Meetup
• 2026-06-19 | Dresden, DE | Rust Dresden
  • Second Meetup
• 2026-06-23 | Paris, FR | Rust Paris
  • Rust meetup #86
• 2026-06-23 | Warsaw, PL | Rust Warsaw
  • Rust Warsaw Meetup: June 2026
• 2026-06-24 | Manchester, GB | Rust Manchester
  • Rust Manchester June Talks
• 2026-06-25 | Berlin, DE | Rust Berlin
  • Rust Berlin Talks: The next generation
• 2026-06-25 | Copenhagen, DK | Copenhagen Rust Community
  • Rust meetup #69
• 2026-07-02 | Edinburgh, GB | Rust and Friends
  • Bevy, Bits, & Cats (Rust July Talks)
• 2026-07-02 | Enschede, OV, NL | Baseflow Tech Meetups
  • AI Summit
• 2026-07-08 | Dublin, IE | Rust Dublin
  • Join us live and INPERSON for Rust 261
• 2026-07-09 | Switzerland, CH | PostTenebrasLab
  • Rust Meetup Geneva

North America

• 2026-06-17 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Rust Study/Hack/Hang-out
• 2026-06-18 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • June, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-06-18 | Nashville, TN, US | Music City Rust Developers
  • Community Meetup
• 2026-06-20 | Boston, MA, US | Boston Rust Meetup
  • Northeastern Rust Lunch, June 20
• 2026-06-24 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground
• 2026-06-24 | Los Angeles, CA, US | Rust Los Angeles
  • Rust LA: Rust-Based Constraint Solvers in 2D Sketching with Zoo Technologies
• 2026-06-25 | Atlanta, GA, US | Rust Atlanta
  • Rust-Atl
• 2026-06-26 | New York, NY, US | Rust NYC
  • Rust NYC's Big Summer Social
• 2026-06-27 | Boston, MA, US | Boston Rust Meetup
  • Somerville Union Square Rust Lunch, June 27
• 2026-07-02 | Saint Louis, MO, US | STL Rust
  • Git is easy?
• 2026-07-04 | Boston, MA, US | Boston Rust Meetup
  • Boston University Rust Lunch, July 4
• 2026-07-09 | Lehi, UT, US | Utah Rust
  • Utah Rust July Meetup
• 2026-07-11 | Boston, MA, US | Boston Rust Meetup
  • MIT Rust Lunch, July 11

Oceania

• 2026-06-25 | Melbourne, AU | Rust Melbourne
  • Rust Melbourne June 2026

South America

• 2026-06-18 | Florianópolis, BR | Rust SC
  • Rust Floripa

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

"The never type is named after the date of its stabilization" was a good joke while it lasted.

– Sergey "Shnatsel" Davidoff on /r/rust

Thanks to Dos Moonen for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by:

• nellshamrell
• llogiq
• ericseppanen
• extrawurst
• U007D
• mariannegoldin
• bdillo
• opeolluwa
• bnchi
• KannanPalani57
• tzilist

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

Added

• Added UMANS_WEBSEARCH_PROVIDER=native|exa support for routing Umans gateway-owned web search requests.

Fixed

• A single MCP tool whose input schema can't be emitted as a valid strict tool schema for the active provider no longer fails the whole turn with HTTP 400. convertTools (openai-responses) now validates each tool's emitted parameter schema for enum/const-vs-type contradictions that pass structural JSON-Schema validation but the provider rejects — e.g. a non-null enum on a type: "null" node, or an enum on an array node — and quarantines just the offending tool with a logger.warn naming the tool and schema path, keeping every other tool usable. Adds findStrictToolSchemaViolation to @oh-my-pi/pi-ai/utils/schema (#2652)
• Fixed OpenAI Responses-compatible streams from Ollama/local hosts dropping arguments for parallel tool calls whose deltas use fc_<call_id> item ids, which left earlier ast_grep calls with {} and failed validation. (#2715)
• Fixed dialect transcript rendering so literal thinking envelopes are unwrapped before adding the dialect's own thinking tags, preventing nested <thinking> output in advisor raw dumps (#2700).
• Fixed Anthropic-compatible Umans requests escaping client tool names and forwarding gateway web search headers so Kimi answers normally instead of returning raw gateway search results.
• Fixed Google Gemini tool calls with toolChoice: "auto" serializing an explicit toolConfig AUTO mode, which can cause Gemini-3 models to leak raw planning JSON instead of executing tools. (#2776)
• Fixed OpenAI-compatible Ollama completions that return empty finish_reason:length after filling num_ctx so they surface an actionable context-window error instead of an empty length stop. (#2774)
• Fixed Codex browser login issuing credentials for the opencode OAuth originator while OMP requests identify as pi, which could make the first authenticated Codex request return 401 (#2696).

@oh-my-pi/pi-catalog

Fixed

• Fixed Kimi output caps for Umans AI Coding Plan and Venice so discovery metadata cannot use context-sized token ceilings as request caps.
• Marked Umans Anthropic-compatible models as client-tool escaped so cached and bundled metadata do not expose web_search as a provider server tool.

@oh-my-pi/pi-coding-agent

Added

• Added the UMANS_WEBSEARCH_PROVIDER environment variable to CLI help for Umans gateway web search backend selection.

Changed

• The eager task (task.eager: always) and eager todo (todo.eager: preferred/always) hidden reminders now re-fire on the auto-continuation turn after a compaction (context-full / snapcompact / handoff / shake). Compaction summarizes away the first-message prelude, so the agent would otherwise silently lose the delegate-via-tasks / phased-todo guidance mid-work; the post-compaction todo nudge is reminder-only and never forces the todo tool onto the resumed turn.

Fixed

• Fixed edit-tool block operations on Emacs Lisp files: .el and .emacs paths now resolve top-level forms for SWAP.BLK, DEL.BLK, and INS.BLK.POST instead of reporting an unsupported-language block-resolution error.
• Fixed PDF reads leaking recoverable MuPDF WASM warnings into the terminal TUI by routing MuPDF output through the file logger before markit-ai loads it (#2766).
• Fixed /exit and /quit waiting one shutdown timeout per hanging extension by running session_shutdown handlers within a shared shutdown window (#2736).
• Fixed GitHub Copilot .github/instructions/*.instructions.md discovery by loading those files as rules that honor applyTo scoping, including always-apply ** files and rule://<name> access for glob-scoped entries (#2731).
• Fixed Windows bash-tool child processes defaulting interpreter pipe I/O to the ANSI codepage by adding UTF-8 encoding defaults when the inherited environment is unset (#2701).
• Fixed /advisor dump raw so Opus 4.5 thinking content that already includes literal <thinking> tags is not rendered with nested thinking tags (#2700).
• The plugin-extensions-discovery test suite no longer writes fixtures into — and rm -rfs the node_modules of — the developer's real ~/.omp/plugins. Its XDG_DATA_HOME isolation was a no-op on Windows (XDG is gated to Linux/macOS) and was bypassed in XDG-migrated Linux/macOS environments, so a local run could delete installed plugins. The suite now isolates the whole config root via an os.homedir() mock plus cleared XDG_* vars, with a pre-write guard that fails if resolution escapes the temp home (#2721).
• Installed plugins whose extensions manifest entry points at a directory of sub-extensions (the standard pi extensions/<name>/index.ts layout, e.g. pi.extensions: ["./extensions"]) are no longer rejected at install (declared extension entry not found on disk) or silently dropped at load. The plugin manifest resolver now resolves a directory the same way as the configured-directory (-e) extension loader: the directory's own package.json omp/pi extensions (authoritative — a missing declared entry is reported instead of falling back to a decoy index), then a direct index.{ts,js,mjs,cjs}, then a one-level scan of sub-extensions (#2713).
• Fixed OpenRouter @upstream routing selectors whose upstream slug also appears in the model id, so openrouter/...@deepseek:high keeps openRouterRouting.only instead of being consumed by provider-scoped fuzzy matching (#2708).
• Fixed omp plugin list --json omitting locally linked plugins that exist only in omp-plugins.lock.json and node_modules symlinks. (#2742)
• Fixed task subagents to install their configured ordered model candidates as child-session retry fallback chains, so retryable provider failures can advance to the next subagent model instead of failing the worker (#2750).
• Fixed empty reasonless aborted assistant turns to auto-retry without switching model fallback, so transient provider-side aborts after tool results do not end headless sessions (#2685).

@oh-my-pi/hashline

Fixed

• Auto-repaired duplicated JSX/XML closing boundary lines at the end of single-line replacement expansions. (#2705)

@oh-my-pi/pi-natives

Added

• Added Emacs Lisp (.el, .emacs, emacs-lisp/elisp) support to native tree-sitter language inference, enabling astGrep/astEdit, summarizeCode, and blockRangeAt on Emacs Lisp source.

@oh-my-pi/pi-tui

Fixed

• Fixed VS Code integrated terminal keypad digit CSI-u input being handled as navigation instead of text.
• Fixed xterm-compatible terminals scrolling the native viewport to the bottom on prompt-editor keypresses by disabling ?1010/?1011 while the TUI owns the TTY and restoring the prior set modes on exit (#2732).
• Fixed CMUX sessions being treated as direct terminals during resize/reset because they do not set TMUX/STY/ZELLIJ and may run with TERM=dumb; the renderer now treats CMUX workspace/surface env markers as multiplexer signals and preserves pane scrollback instead of emitting ED3 (CSI 3 J).
• Fixed a self-sustaining resize-redraw storm in Warp: the non-multiplexer resize fast path borrows the alternate screen, and Warp re-reports a one-row-different size whenever the alt buffer is toggled, so each drag frame fed back a fresh resize event and the TUI flooded ED3 full repaints with stable geometry. Resize now repaints in place (no alt-screen borrow, no ED3 rewrap) on terminals that re-report size on alt-screen toggles, matching the multiplexer path. Overridable with PI_TUI_RESIZE_IN_PLACE=1|0.

What's Changed

• fix(ai): route prefixed Responses tool deltas by @roboomp in #2719
• test(plugins): isolate discovery test from real ~/.omp on all platforms by @AsafMah in #2722
• fix(coding-agent): load GitHub Copilot instruction rules by @roboomp in #2734
• fix(tui): stop Warp resize feedback-loop redraw storm by @sorphwer in #2741
• fix(cli): speed up exit shutdown handlers by @roboomp in #2745
• fix(cli): list linked local plugins by @roboomp in #2746
• fix(providers): handle Umans Kimi output caps and web search by @oldschoola in #2751
• fix(agent): retry subagent model fallback chains by @roboomp in #2753
• fix(tui): detect CMUX as multiplexer by @pathard1128 in #2755
• fix(coding-agent): route MuPDF warnings to logger by @roboomp in #2772
• fix(ai): omit Google AUTO toolConfig by @roboomp in #2782
• feat(ast): add Emacs Lisp tree-sitter support by @ryjm in #2693
• fix(ai): unwrap thinking envelopes in raw dumps by @roboomp in #2702
• fix(tool): default Windows bash children to UTF-8 by @roboomp in #2704
• fix(hashline): drop duplicated JSX boundary echoes by @roboomp in #2709
• fix(providers): preserve OpenRouter upstream routing by @roboomp in #2710
• fix(openai-responses): quarantine invalid tool schemas instead of failing the whole turn (#2652) by @AsafMah in #2711
• fix(plugins): resolve directory extension manifest entries one level deep by @AsafMah in #2714
• fix(tui): preserve scrollback while editing by @roboomp in #2733

New Contributors

• @sorphwer made their first contribution in #2741
• @pathard1128 made their first contribution in #2755
• @ryjm made their first contribution in #2693

Full Changelog: v16.0.1...v16.0.2

Rust generics have a Sized bound by default today

In today’s Rust, every type parameter (except for Self) has a default bound called Sized:

// So this function...
fn identity<T>(t: T) -> T {
    t
}

// ...is actually short for
fn identity<T>(t: T) -> T
where
    T: Sized, // <-- Added by default!
{
    t
}

A type T implements Sized if the compiler can compute the size of a T value at compilation time. This is true for almost every type, with a few notable exceptions. Consider [u32], which refers to “some number of u32 instances”. We know that a single u32 is 4 bytes, but without knowing how many u32 there are, you can’t know the size of [u32]. This means you can’t have a value of type [u32] on the stack (how big should the stack frame be?).

You opt out with ?Sized

However, if you have a function like by_ref, that just takes the value by reference (i.e., by pointer), you shouldn’t need to know how big the [u32] value is, because you’re not manipulating it directly. You can have a type parameter U that doesn’t require Sized, but you have to explicitly “opt out” from the default bound:

fn by_ref<U>(t: &U)
where
    U: ?Sized, // <-- Opt out from the default
{ }

As a fun bit of historical trivia, this system was introduced way back in 2014 to accommodate Dynamically Sized Types. Before that, &[u32] was actually a built-in, indivisible type; we even wrote it like [u32]/& for a time.¹

But Sized vs ?Sized isn’t enough for everything we need

The Sized vs ?Sized design has served us reasonably well but it is also showing its limits. It turns out that “value has a statically computable size” vs “each value has a distinct size computable at runtime” doesn’t cover all the things you might want. For example, extern types are types whose values have no known size, even at runtime. And then Arm’s Scalable Vector Extensions want to describe SIMD types where every value of the type has the same size (unlike str and [T], where each value can have a different length) but where that size is not known until runtime.

A richer Sized hierarchy

Rather than just Sized or ?Sized, what we really want is to have a richer hierarchy. The current plans look something like this:

flowchart TD
  subgraph S["Sizedness traits"]
      Sized[["Sized (default)"]] -- extends --> MetadataSized
      MetadataSized -- extends --> MaybeSized
  end
  

where

• trait Sized means that all values have the same size and that size can be computed knowing only the type.
• trait MetadataSized means that values can have different sizes and that size can be computed given the metadata attached to a reference to the value. Examples include [T] or dyn Trait.
• trait MaybeSized is implemented for all values and tells you nothing about the value’s size.

Two caveats:

1. I’m excluding the way that Arm’s scalable vector extensions fit into this, because it’s orthogonal.
2. The trait names aren’t settled. I’m using the names I understand the libs-api team to prefer; they’re not my favorites, but that’s ultimately the team who owns stdlib bikesheds, so I defer to them.²

Problem: ?Sized notation doesn’t scale to this hierarchy

But now we have a kind of problem. The ?Sized notation was predicated³ on the idea that users should specify the default bound they are opting out of – i.e., the ? is meant to say “I don’t know if this is Sized or not” (unlike the default, where you know it is Sized). But “opting out” from a bound doesn’t work so well with a multi-level hierarchy. When you write ?Sized, does that correspond to T: MetadataSized (but not T: Sized)? And what if we want to insert another level in between T: MetadataSized and T: Sized later? Then we either have to change what T: ?Sized means (to refer to the new bound) or we have to have T: ?Sized drop two levels down the hierarchy. Even more annoying, what do we do while that middle rung is unstable? Surely T: ?Sized shouldn’t refer to an unstable trait… what if we decide to remove it

Solution: only bounds

The new proposal is to write T: only MetadataSized or T: only UnknownSized instead of T: ?Sized. An only bound combines two things:

1. Like any bound, it includes a “minimum requirement” – i.e., T: only MetadataSized means that T must implement at least MetadataSized.
2. It additionally disables some default bounds – i.e., we will not add the default T: Sized bound.

The name only comes from the fact that T: Sized implies T: MetadataSized. So the default of T: Sized already means that T: MetadataSized for free; but when you write only MetadataSized, you are saying “I don’t need the full hierarchy, just MetadataSized will do”.

only bounds work like normal bounds: ask for what you need

A nice feature of only bounds is that they work more like a regular bound. Whereas a ? bound is saying “I don’t need this”, an only bound is saying what you do need. So e.g. if you are writing a function that just has references to values of type T does not care what their size is, you can write

fn by_ref<U>(u: &U)
where
    U: only MaybeSized,
{}

If you are writing a function that does need to compute the size of values of type V, you can ask for that capability:

fn checks_size<V>(v: &V)
where
    V: only MetadataSized,
{
    std::mem::size_of_val(v)
}

only bounds allow for new levels to be added later

A nice feature of only bounds is that, later on, we can add new levels to the hierarchy, and they work normally. For example, suppose we wish to add something like Aligned where the size is not known at compilation time but the alignment is. We could change the hierarchy to

trait Sized: Aligned
trait Aligned: MetadataSized // <-- new!
trait MetadataSized: MaybeSized
trait MaybeSized

and functions with U: only MaybeSized (like by_ref) and with V: only MetadataSized (with checks_size) would continue to have the same requirements. But new functions could be written with T: only Aligned that would use the new bound. And there is no conflict with stabilization; code that writes T: only Aligned can be considered unstable until that middle hierarchy is finalized.

only bounds compose normally

Like any other bound, only bounds are combined with other bounds to form the overall requirements. So it is possible to write e.g. T: only MetadataSized + Sized. This is equivalent to T: Sized and therefore equivalent to the default and therefore kind of pointless, but you can write it. Similarly, given that trait Clone: Sized, if you write T: only MetadataSized + Clone, that is kind of pointless too: you might as well write T: Clone, which would be equivalent. We plan to have a warn-by-default lint for that.

Scaling only to other “default bound families” (speculative)

The final strength of only bounds is that they allow us to introduce whole new families of default bounds. One example is the idea of introducing a Move bound. Note that this is a distinct feature and is not covered under the current RFC.

All types in Rust today are “movable” and “forgettable”, meaning that you can memcpy the value from place to place so long as you stop using the previous location and you can recycle the memory where it is stored without running the value’s destructor. There is one notable exception – when you pin a value, you it can no longer be moved, and you must run its destructor before its memory is reused – but otherwise this is a hard-and-fast rule. And that’s annoying!

The problem is that not being able to guarantee that a destructor runs blocks a lot of unsafe code patterns. For example, scoped tasks a la rayon depend on a destructor for safety. In sync code, this works because we’ve decided it’s UB to unwind a stack frame without running the destructors of values stored there, and so if you put a local variable on the stack, you can be sure its destructor will run. But that doesn’t work in async code! And there are times when unwinding without running destructors would be nice.

The solution is to introduce a second family of default traits. Unlike the Sized family we saw before, this family defines fine-grained capabilities about how values of that type can be used:

flowchart TD
  subgraph A["Accessability traits"]
      Forget[["Forget (default)"]] -- extends --> Leak
      Leak -- extends --> Destruct
      Destruct -- extends --> Access
      Move[["Move (default)"]] -- extends --> Access
  end
  Copy -- extends --> Move
  

The meaning of the traits are as follows:

• Forget, the default, says that you can recycle the memory for a value without running its destructor.
• Leak says that you can skip running a destructor for a value, but only if you never reuse the memory where the value resides.
• Destruct says that if you have a value of this type, you can reuse the memory where it resides by running its destructor.
• Copy, which already exists, says that you can memcpy the place and keep using the original place; it’s not really a default, but I included it because it is relevant.
• Move, another default, says that you can memcpy the value to a new place if you stop using the original.
• Access is the root of this family. It indicates a value that can be “accessed in place” (basically, any value at all).

This introduces new checks into the compiler:

• When you move a value (i.e., a = b where b is not used later), we will check that the type implements Move (whereas today, it is always allowed).
• When you exit a scope, we will check that the values in each local variables have either been moved or have a type that implements Destruct.

Some implications:

• If your function owns a value of type T: only Destruct, then you must destruct it before your function returns. You can’t move it (because you don’t know if it implements Move) and you can’t leak or forget it either.
• If your function owns a value of type T: only Move, then the only thing you can do with it is move it somewhere else. You can’t drop it (because you don’t know if it implements Destruct).
• No function can own a value of type T: only Access, because you wouldn’t be able to move it nor drop it, and hence you could not return. But you could have such a value (say) in a static.

How only bounds could work in the presence of multiple families

The spur for writing this blog post was a question in a lang team meeting on how only bounds ought to work given the existence of multiple “families” of default traits, as I described above. Although the current RFC is looking only at the Sized traits, we expect to look at the “access family” in a future RFC, so we want to be sure we are not making any decisions that won’t scale to cover both.

The way I imagine it working is like this. Each default traits is associated with one or more “families”. When you have an only bound, it “opts out” from all default traits in each family that the trait is associated with:

• T: only Move opts out from Forget, Leak, Destruct – but not Sized.
• T: only Destruct opts out from Forget, Leak, and Move – but not Sized.
• T: only MetadataSized opts out from Sized – but not Forget or Move.
• T: only MaybeSized opts out from Sized – but not Forget or Move.

You may also want to “opt back in” to some defaults. For example, T: only Move + Destruct is a sensible thing to do. It means values that can be moved and destructed but not leaked or forgotten.

Examples

Option::map requires only Move

map is an example of a function that only needs Move. You need to be able to destructure self (which moves the optional value out into a local variable v and then invoke the closure op, which again moves the wrapped value v:

impl<T: only Move> Option<T> {
    fn map<U: only Move>(
        self,
        op: impl FnOnce(T) -> U,
    ) -> Option<U> {
        match self {
            Some(v) => Some(op(v)),
            None => None,
        }
    }
}

One interesting thing is the result type U. Using only the stuff I wrote in this blog post, it needs to be only Move, because the result will be moved into the Some value and so forth. But in-place-init would allow for this definition to omit the U: only Move bound because we could statically guarantee that the Option will be constructed in place and never moved after that.

Option::or requires only Move + Destruct

The a.or(b) method on Option returns a if it is Some and otherwise returns b. This is an interesting one because the value b may not be used and therefore requires only Move + Destruct bounds.

impl<T: only Move> Option<T> {
    fn or(
        self,
        alternate: Option<T>,
    ) -> Option<T>
    where
        T: Destruct, // <-- because it may be dropped
    {
        match self {
            Some(v) => Some(v), // drops `alternate`
            None => alternate, // moves `alternate`
        }
    }
}

Rc requires MaybeSized + Leak

The Rc type is an example where we would want to relax bounds from both families:

struct Rc<T: only MaybeSized + only Leak> {}

I believe the proper minimum bounds for Rc are:

• only MaybeSized because while it can store MetadataSized or Sized things, it doesn’t have to, it can also store things of an non-computable size (although it does raise the question of how they would be freed, but that’s an allocator concern).
• only Leak because Rc values can form cycles and thus we can’t ever guarantee the destructor will be run. Interestingly, Rc<T> can implement Forget even its contents don’t.

Frequently asked questions

What is actually under RFC today?

The post may be a bit confusing here. The current RFC is looking only at the proposed “Sized” traits. The Access family is a speculative future extension that we are exploring but at a much earlier stage.

Can I use only with any trait?

In the beginning, the plan would be that only can only be used for well-known, default traits (e.g., Move, Sized, etc). In the future though there are some thoughts to generalizing it.

Why not opt out from all defaults at once?

An alternative that was proposed is to have the opt-out be per-type-parameter. So you might write something like

fn foo<T: MetadataSized + ?default>

which would “opt out” from all defaulted bounds. Obviously we’d have to bikeshed the syntax, but ignore that for now. The question is whether opting out of all defaults is better than opting out of a single family. I prefer the per-family option for two reasons:

• First, things like T: only Move demonstrate that you might very reasonably which to opt out from a single family but retain the default Sized bound. I think it’s likely that there will be many functions that want to opt out of Sized or Forget but not both.
  • You might think that we could make Move: Sized to get the same effect, but I think that would be a mistake. The fact that a value’s size must be computed dynamically doesn’t inherently mean it can’t be moved.
• Second, it makes it harder to introduce new families later, if we decide there are other orthogonal properties of values that we’d like to relax.

Why do you think it’s likely that people want to opt out of being Sized xor Forget but not both?

Because the Forget, Move, and similar traits mostly apply to owned values. The examples we saw with Option<T> were quite typical. And when you are moving values of type T around, you need that T to be Sized.

But we saw that Rc wanted to opt out of both families with only Leak + only MetadataSized, right?

Yes, that’s true, and I think that particular combo will be common. I don’t think that’s an argument for the ?default approach on its own, though, particularly since that case would not be much cleaner or shorter…

impl<T: ?default + Leak + MetadataSized> Rc<T> {}

…what I think that argues for is actually trait aliases and shorthands.

Wait, trait aliases and shorthands? Can you elaborate?

Yes! I think that a future RFC could extend only bounds to allow you to define trait aliases with “only bounds” as supertraits:

trait RefCountable = only Leak + only MetadataSized;

// Equivalent to:
// trait RefCountable: only Leak + only MetadataSized {}
// impl<T> RefCountable for T where T: only Leak + only MetadataSized {}

You could then use an only RefCountable bound to define Rc<T>:

impl<T: only Refcountable> Rc<T>

Without the only, T: Refcountable would just be a regular trait bound and would not opt-out from any defaults.

Can we use a “root” trait to opt out of all defaults?

Yes, we could! You could define an alias like Value:

trait Value = only Access + only MaybeSized;

Since Access and MaybeSized are both implemented for all types, this effectively becomes part of both families:

flowchart TD
  subgraph All["All default families"]
  subgraph A["Access family"]
    Forget[["Forget (default)"]] -- extends --> Leak
    Leak -- extends --> Destruct
    Destruct -- extends --> Access
    Move[["Move (default)"]] -- extends --> Access
  end

  subgraph S["MaybeSized family"]
    Sized[["Sized (default)"]] -- extends --> MetadataSized
    MetadataSized -- extends --> MaybeSized
  end

  Access -- extends --> Value
  MaybeSized -- extends --> Value
  end
  

Then you can do T: only Value and opt out from both families at once.

If we did that, what would happen if we wanted to add a new family in the future?

Ay, there’s the rub. If we wish to add a new family in the future, let’s say for values that don’t live in the same memory space (T: only Distributed…?), then Value would be “out of date” because code written against Value would still be assuming uni-memory-space values. But we could make Value into an edition-dependent alias or something like that, as has been discussed.

Can we decide whether we want Value later?

Yes! We can introduce a root trait at any time. So we can add the Sized-ness family first, then the Access family, and then see how we feel. Maybe we find people are very commonly opting out of both– in which case, some aliases are useful, or perhaps a Value variant.

The only way we might “regret” it is if, in practice, people usually just opted out of both and then opted back in to what they want specifically. But we already know that T: only Move will be common and clearly T: only Value + Move + Sized is more awkward in that case, so I don’t consider that very likely.

Why the name Destruct and not Drop?

That name comes from the const trait RFC. There are a few reasons to move away from Drop. The first is that it is possible to have a destructor even if you don’t implement Drop: Drop really refers to user-provided logic in the destructor, but the compiler adds its own logic (“drop glue”, it’s sometimes called) to drop all the fields in the value. The second reason is that the Drop trait itself needs some revision, so moving away from that name lets us have other ways to specify custom logic (e.g., pinned self, or by-value, etc etc).

How does this interact with const traits anyway?

Quite beautifully! In fact, the proposal from Arm for SVE is to introduce the idea of T: const Sized being “a type whose size can be computed at compilation time”, which I find quite elegant. Similarly T: const Destruct was proposed by the const RFC as a way to say that a value has a constant destructor.

It’s annoying to write T: only Move + Destruct. Couldn’t we have Destruct imply Move so that I can just write T: only Destruct?

My original proposal for introducing linear types had Destruct extending Move. This would mean that the Option::or proposal could simply do U: only Destruct and not U: only Move + Destruct. However, Alice Ryhl and others pointed out that there are immovable types that must nonetheless be destructed, so it doesn’t make sense to combine those.

Where can I learn more?

The Project Goal has a lot of details. The latest updates are available on the tracking issue. If you like watching videos, I recommend David Wood’s Rust Nation talk.

Conclusion

I want to close with a meta-observation and a big shout-out to the Arm team. I think they are showing how awesome open-source can be. The Arm team’s primary motivation is adding support for Scalable Vector Extensions. This helps Rust make full use of Arm processors. This is, in and of itself, a laudable goal, and valuable to Rust: One of Rust’s assets, in my view, is that it gives you access to all the power your processor has to provide, and that should include unique extensions.

But rather than add the feature as a kind of special-case extension to Rust, the Arm team is going further and driving a general purpose improvement, one that will unlock a bunch of other features (extern types and, to some extent, guaranteed destructors; guaranteed destructores themselves unlock scoped async threads and better Wasm integration). I love that.

Generic themes of this release were refactoring the old WPF code base and moving away from platform-dependent implementations to make reuse easier via our ILSpyX package.

A few notable picks from the "What's new" department for you to check out: WebCIL and standalone ECMA-335 metadata support, as well as diagramming (either via ilspycmd or assembly context menu). And in general quality-of-life improvements like the ability to disable automatic assembly loading, performance improvements via DATAS and future-proofing for .NET 10.

New Language Features

• Add support for C# 12 primary constructors.
• Add support for C# 12 'ref readonly' parameters
• Added support for switch on (ReadOnly)Span<char> using a compiler-generated hash function.
• Added new a.GetValueOrDefault(b) -> a ?? b transform for side-effect-free default values.
• Support types that provide DisposeAsync without implementing IAsyncDisposable.
• Updated pattern detection to Roslyn 4.12

Enhancements

• Added support for reading WebCIL assemblies (IL embedded in WASM) (see #3184)
• Added support for reading standalone ECMA-335 metadata (portable PDB and other metadata blobs) (see #3149)
• #3118: Add "Clear assembly list" menu item.
• #2893: Add option to disable automatic assembly loading.
• Allow implicit conversions in switch
• IL output: Add indentation level to make it easier to see custom attributes belonging to interface implementations.
• IL output: Print metadata token of custom attribute.
• Replace native interop CommandLineToArgvW with parsing in Process.Unix.cs from System.Diagnostics.Process #3201
• Natural Sort without interop #3196
• AOT and x-plat changes #3203
• Allow running tests on ARM64 (see #3231)
• Alow collecting analyzers annotated with ExportAnalyzerAttribute (see #3239)
• Fix #3237: Use ref readonly locals for readonly.ldelema
• Fix #3001: Support new resources format in ResourcesFile/ResXResourceWriter
• Fix #3134: Include newobj, initobj and call instructions in TypeInstantiatedByAnalyzer
• Fix #3089: Add comment regarding .constraint prefix expressed as cast in C#
• Fix #3372: Fix loading a DLL that contains byte sequences matching ZIP central directory
• Use Microsoft.Sbom.Targets in NuGets #3346

Contributions

• Diagramming feature by @h0lg (see #3324)
• Various WPF-related refactorings by @tom-englert (see #3257, #3266, #3274, #3283, #3285, #3291, #3292, #3294, #3295, #3297, #3298, #3299, #3302, #3308, #3314, #3325 and #3335)
• High DPI fixes by @CreateAndInject (see #3348 and #3350)
• TreeView: Add referenced types, members and exported types under references (#3092, @fowl2)
• Adjust colors of AvalonEdit built-in highlightings for dark themes (#3138, @ltrzesniewski)
• Add support for Mono C# compiler 2.6.4 pinned region with array variable (#3110, @ElektroKill)
• Add smooth scrolling to settings panels and DecompilerTextView (see #3244 by @tom-englert)
• Ignore empty version directories of dotnet (#3265 by @Herrmel)
• Missing DecompilerSettings by @naratteu (see #3356)
• Fix metadata display of DynamicLocalVariable and DefaultNamespace custom debug information (#3111, @ElektroKill)
• Read and use tuple element names and dynamic type information from PDBs (#3114, @ElektroKill)
• Bugfix: infinite loop in DetermineEffectiveAccessibility (#3164, @yzdeveloper)
• Decompiler Settings: Checkbox in group header does not reflect state of the group (see #3252 by @tom-englert)
• Fix Derived Types Node always being empty (#3280 by @Applesauce314)

Performance

• Activate Dynamic Adaptation To Application Sizes (DATAS) (#3122).
• RDP hardware acceleration (#3122): Enabling hardware acceleration for Remote Desktop Protocol (RDP) to boost performance.
• Performance: Initialize ToolPanes in DockWorkspace.InitializeLayout() instead of the property getter to avoid WPF seeing them in InitializeComponent() and rendering all panes docked at the right before the layout is properly initialized.

Breaking Changes

• ICSharpCode.Decompiler: Added MetadataFile base class for PEFile
• ICSharpCode.Decompiler: IModule.PEFile is now named IModule.MetadataFile
• ICSharpCode.Decompiler/ILSpyX: Added IFileLoader API to allow for easier extensibility of supported file formats (see #3191)
• ILSpy: Split BAML decompiler into library and add-in (see #3178)
• ILSpy/ILSpyX: Moved non-UI analyzer API to ILSpyX (see #3186)
• ICSharpCode.Decompiler: IProjectFileWriter and IProjectInfoProvider APIs are now public (see #3151 and #3191)
• @file support with breaking changes to command line options #3205
• New single instance handling #3212
• Remove IsRef, IsOut and IsIn flags from IParameter
• Replace ParameterModifiers with ReferenceKind.

Bug fixes

• Fix #3072: Ignoring resources with the same name as a namespace.
• Fix bug in UnknownType: Ensuring that the FullName of nested unknown types contains the outer type name(s), not just the namespace and nested type name.
• Fix #3153: Always using SHA1 for public key tokens.
• Fix ILSpy for ZIP files/VSIX with bundle signatures: Enabling ILSpy to open ZIP files and VSIX packages containing bundle signatures.
• Omit package entries from the treeview that denote the directory.
• Fix #3142: Exception when analyzing source of library with global assembly attributes
• Fix #3113: Remove GetAlternativeName and instead reuse existing names, if there are no conflicts.
• Fix #3197: Bug when trying to read a bundle/archive file
• Fix #3189: Support primitive types in Expression.Constant(object) pattern in Expression Trees
• Fix #3209: Ensure using directives are added for extension methods in higher level patterns such as: foreach -> GetEnumerator(), collection initializer -> Add() and deconstruction -> Deconstruct().
• Fix #3255: Ignore exceptions while decoding sequence point blobs.
• Fix #2166: Unnecessary uint casts/conversions for certain bitwise operations
• Fix #3310: Filter out copy-constructor only if it's an actual record type.
• Fix #3319: KeyDownEvent field reference was replaced with KeyDown event reference.
• Fix #3349: Make ILSpy ready for .NET 10
• Fix #3361: switch-value conversion was losing its target type.

And many other fixes, for a full list click here.

• resources/jsconfig: Remove deprecated baseUrl setting ff2903a @bep #14991 #14996
• all: Adjust tests for deprecated link and image render hook settings ca68936 @jmooring
• all: Run go fix ./... 781fabf @bep
• pagesfromdata: Use relative path for content adapter template metrics 1d018ef @anupamojha-eng #14999
• ci: Re-add macos-latest to the test matrix 121bc6c @bep
• images: Deprecate Imaging.Compression and move it down to webp and avif configs cf18b82 @bep #14998
• Only support the latest Go version 98ad9b3 @bep #14997
• page: Add IsBranch and deprecate IsNode b89e7fe @bep #11574
• images: Force cache invalidation for AVIF target e8fefc8 @bep #14990
• images: Add a per-format AVIF hint setting a043d3e @bep #14992
• images: Make AVIF chroma subsampling content-aware via the hint 341f575 @bep #14987
• Cap AVIF lossy quality at 99 248241b @bep #14981
• config: Deprecate the glogal imaging quality setting 4e47d95 @bep #14979
• images: Make 60 the default quality for AVIF 03b4b54 @bep #14979
• livereload: Disconnect from websocket server on pageswap 79be053 @bep #14983
• tpl/tplimpl/embedded: Prevent leading newline in sitemap template 0f44046 @bep #14977
• images: Recover from memory alloc errors in WASM image processors 4e17421 @bep #14985
• images: Add quality setting per image format b01ecd4 @bep #14957
• misc: Remove duplicate words in comments 45c00b7 @jmooring #14936 #14950 #14965
• Add some PNG to AVIF golden test cases 28d882a @bep

Dependency Updates

• build(deps): bump github.com/bits-and-blooms/bitset 0d29fc8 @dependabot[bot]
• build(deps): bump github.com/tetratelabs/wazero bb57404 @dependabot[bot]
• build(deps): bump github.com/rogpeppe/go-internal from 1.14.1 to 1.15.0 7d1b1fb @dependabot[bot]
• build(deps): bump github.com/getkin/kin-openapi from 0.138.0 to 0.139.0 77a1147 @dependabot[bot]

Hierarchical Integration of WebAssembly in Serverless for Efficiency and Interoperability

Mohammadamin Baqershahi, Changyuan Lin, and Visal Saosuo, University of British Columbia; Paul Chen, Huawei Technologies Canada; Mohammad Shahrad, University of British Columbia

Modern serverless systems suffer from low resource efficiency, which maps to high per-unit costs.
This comes from the high isolation overhead (e.g., low resource sharing, slow startup, etc.), as well as resource wastage incurred by conservative resource scaling (e.g., keep-alive). Language runtimes such as WebAssembly (Wasm) can reduce isolation overhead without compromising security. Existing Wasm-based serverless approaches fall into one of these categories: supporting only Wasm workloads, failing to leverage existing capabilities of modern serverless and cloud platforms, or falling short of leveraging Wasm’s true potential. This work introduces a dense hierarchical architecture to securely co-locate Wasm-based applications from different customers within the same container sandbox. We show how this design preserves the container-based serving model, which allows leveraging existing platform capabilities and supporting non-Wasm-based workloads. Our system, Wasabi, leverages this architecture alongside resource-aware scaling, queuing, and overbooking to offer much higher density than state-of-the-art serverless systems with similar or better performance.

View the full NSDI '26 program at https://www.usenix.org/conference/nsdi26/technical-sessions

1. Generating structured inputs from scratch with the arbitrary crate

2. Mutating existing inputs from the fuzzer’s corpus in a structure-aware manner, thereby producing new structured inputs, via the fuzz_mutator! hook

While the two methods are not technically mutually exclusive, combining the two can be difficult and engineering resources are finite. So:

If we are only implementing one approach, is generation or mutation better?

To help answer this question, I implemented structure-aware generation and mutation of guaranteed-valid WebAssembly (Wasm) instruction sequences. This task is small enough to be easily understandable but large enough and real enough to (hopefully) be representative and applicable to other domains, or, at the very least, interesting.¹ To evaluate their effectiveness, I used Wasmtime as the SUT, libfuzzer-sys as the fuzzing engine driving everything, and then compared code coverage over time when using mutation-based fuzzing versus generation-based fuzzing.

Additionally, there are many ways we can generate pseudorandom WebAssembly instruction sequences. In this experiment, I’ve evaluated three methods:

1. Unconstrained instruction sequence generation followed by a fixup pass to ensure validity

2. Generating valid instructions in a forwards, bottom-up manner (from operands to operators)

3. Generating valid instructions in a backwards, top-down manner (from operators to operands)

In contrast, while there are surely many ways to mutate a given WebAssembly instruction sequence into a new, valid instruction sequence, I’ve only implemented one method: perform an arbitrary instruction insertion, deletion, or replacement, producing a new but probably-invalid instruction sequence, and then run the same fixup pass mentioned previously to ensure validity. This is the direct mutation-based equivalent of the first generation-based method.

Before continuing further, I want to disclose that I am the author of wasm-smith and mutatis, and a maintainer of Wasmtime, arbitrary, libfuzzer-sys, and cargo-fuzz. That is, while I am familiar with Wasm, fuzzing, fuzzing Wasm, and both the arbitrary and mutatis crates, I may also be propagating my own biases into these implementations.

Background

Generation-Based and Mutation-Based Fuzzing

A generation-based fuzzer uses a generator to create a pseudo-random test cases from scratch, feeds these into the system under test, and reports any failures to the user:

fn generation_based_fuzzing<T>(
    // A test-case generator.
    generator: impl Fn() -> T,
    // A function to run the system under test with a
    // generated test case, returning a result that
    // describes whether the run was successful or
    // not.
    run_system_under_test: impl Fn(&T) -> FuzzResult,
) {
    loop {
        // Generate an input.
        let input = generator();

        // Run the input through the system under test.
        let result = run_system_under_test(&input);

        // If the system crashed, panicked, failed an
        // assertion, violated an invariant, or etc...
        // then report that to the user.
        if let Err(failure) = result {
            report_to_user(&input, failure);
        }
    }
}

On the other hand, mutation-based fuzzers are given an initial corpus of inputs and create new inputs by mutating existing corpus members. They run each new input through the SUT, report failures the same as before, and if the new input was “interesting” (for example, exercised new code paths in the SUT that weren’t previously covered in any other input’s execution) then the new input is added into the corpus for use in future test iterations:

fn mutation_based_fuzzing<T>(
    // A corpus of test cases.
    corpus: &mut Corpus<T>,
    // A function to pseudo-randomly mutate an existing
    // input into a new input.
    mutate: impl Fn(&T) -> T,
    // A function to run an input in the system under
    // test, returning a result that describes whether
    // the run was successful or not.
    run_system_under_test: impl Fn(&T) -> FuzzResult,
) {
    loop {
        // Choose an old test case from the corpus.
        let old_input = corpus.choose_one();

        // Pseudo-randomly mutate that old test case,
        // creating a new one.
        let input = mutate(old_input);

        // Run the input through the system under test.
        let result = run_system_under_test(&input);

        // If the system crashed, panicked, failed an
        // assertion, violated an invariant, or etc...
        // then report that to the user.
        if let Err(failure) = result {
            report_to_user(&input, failure);
        }

        // If the input was interesting, for example if
        // it executed previously-unknown code paths,
        // then add it into the corpus for use in a
        // future iteration.
        if result.input_was_interesting() {
            corpus.insert(input);
        }
    }
}

The two approaches are not mutually exclusive and hybrid generation- and mutation-based fuzzers exist.

More resources:

• Wikipedia’s “Fuzzing” article’s “Reuse of existing input seeds” section
• The Fuzzing Book’s Mutation-Based Fuzzing chapter
• Writing a Test Case Generator for a Programming Language

Structure-Aware Fuzzing

Structure-unaware fuzzing will generate pseudorandom byte sequences and pass them directly to the SUT. If the SUT expects some sort of structured input, e.g. the source text for a programming language, it is likely that these byte sequences are invalid and will be rejected early by the SUT’s frontend. For example, when fuzzing a compiler, the input is rejected as syntactically invalid by the parser or rejected as semantically invalid by the type checker. This can be useful when hardening a tokenizer, parser, or type checker, but is less useful when hunting for misoptimization in the mid-end or bad instruction encoding in the backend because the inputs are unlikely to make it that far through the compiler’s pipeline.

Structure-aware fuzzing will produce inputs that match the SUT’s expected input format. Returning to the compiler-fuzzing example, structure-aware fuzzing lets us generate valid programs for the compiler, so we can exercise more of the mid-end and backend, rather than just the frontend.

Structure-aware fuzzing is often generation-based: for example using grammar-based fuzzing to generate pseudorandom strings from a given language grammar or language-specific tools like csmith and wasm-smith that generate C and WebAssembly programs respectively. But structure-aware fuzzing can also be mutation-based: libFuzzer’s custom mutator example implements a structure-aware mutator for zlib-compressed strings, where the raw input is decompressed, the decompressed data is mutated, and then the mutated data is recompressed to provide the new raw input. The mutator is aware of the SUT’s zlib-compressed input structure.

More resources:

• Wikipedia’s “Fuzzing” article’s “Aware of input structure” section
• google/fuzzing on structure-aware fuzzing
• The rust-fuzz book on structure-aware fuzzing

The arbitrary Crate

The arbitrary crate helps Rust developers write custom structure-aware generators for fuzzing. It provides building blocks and abstractions for translating a raw byte sequence (usually from a fuzzing engine) into a structured type, effectively interpreting the raw bytes as a “DNA string” or set of predetermined choices for its decision tree. The library also provides a derive(Arbitrary) macro to automatically implement its functionality for a given type.

Because arbitrary is effectively implemented by combining decision trees, it is extremely easy to create imbalanced trees and unintentionally bias the distribution of generated test cases.

The mutatis Crate

The mutatis crate is, at a high-level, performing the same role for authoring structure-aware mutators that arbitrary plays for generators. That is, it provides Rust developers with abstractions and combinators for creating custom structure-aware mutators. It also provides a derive(Mutate) macro to automatically implement its functionality for a given type.

mutatis is designed to resist bias via a two-phase design: first, it enumerates all of the candidate mutations that could be applied to a test case, and only afterwards chooses a particular random mutation from the candidate set to actually apply.

WebAssembly

WebAssembly is a virtual instruction set designed to be safe, portable, and fast. It is a stack machine where an instruction’s operands are popped off a stack during execution and results pushed. It has sandboxed linear memories, global variables, and local variables (the latter two effectively being two kinds of virtual registers). The following instruction sequence computes a * 3 and stores the result into memory at address p:

;; []
local.get $p
;; [p]
local.get $a
;; [p, a]
i32.const 3
;; [p, a, 3]
i32.mul
;; [p, a*3]
i32.store
;; []

Generator and Mutator Implementation

The range of all three generators and the mutator is the same universe of WebAssembly programs. They are all implemented on top of the same Module and Inst types, and, given enough time, none is capable of producing an instruction sequence that another cannot. This helps ensure that our comparison is apples-to-apples. However, due to their different implementation techniques, they do produce different distributions of WebAssembly programs within that universe, and produce test cases at different speeds from one another, which ultimately affects how efficiently they exercise the SUT.

All of the generators are built on top of the arbitrary crate. The mutator is built on top of the mutatis crate.

The Module type is our structured fuzzing input. It describes a WebAssembly module containing a variable number of linear memories, a variable number and type of globals, and one function with a variable number and type of parameters and results and a variable instruction sequence:

/// A WebAssembly module of the shape:
///
///     (module
///       (memory ...)
///       (memory ...)
///       ...
///
///       (global ...)
///       (global ...)
///       ...
///
///       (func (export "run") (param ...) (result ...)
///         ...
///       )
///     )
pub struct Module {
    num_memories: u32,
    globals: Vec<Global>,
    param_types: Vec<ValType>,
    result_types: Vec<ValType>,
    instructions: Vec<Inst>,
}

The Inst type is an enum of all the WebAssembly instructions the implementations support, which is all of the integer, float, SIMD, memory, local, and global instructions. Control-flow, threading, table, and GC instructions are not supported. Here is a subset of Inst’s definition:

/// A WebAssembly instruction.
pub enum Inst {
    Drop,
    LocalGet(u32),
    GlobalGet(u32),

    // ...

    I32Const(i32),
    I32Add,
    I32Sub,
    I32Mul,

    // ...

    I64Const(i64),
    I64Add,
    I64Sub,
    I64Mul,

    // ...

    F32Const(f32),
    F32Add,
    F32Sub,
    F32Mul,

    // ...

    F64Const(f64),
    F64Add,
    F64Sub,
    F64Mul,

    // ...

    I32WrapI64,
    I64ExtendI32S,
    I64ExtendI32U,

    // ...

    V128Const(i128),
    I8x16Add,
    I8x16Sub,

    // ...

    I32Load(u32),
    I64Load(u32),

    // ...

    I32Store(u32),
    I64Store(u32),

    // ...

    MemorySize(u32),
    MemoryGrow(u32),
}

There is an Inst::operand_types method that returns the types that the instruction pops from the stack, and an Inst::result_type method that returns the type of the value that the instruction pushes onto the stack, if any. Finally, the Module::to_wasm_binary method encodes the module into WebAssembly’s binary format, so it can be fed into Wasmtime. These methods are used, directly or indirectly, in every generator and mutator implementation.

arb

The arb generator leverages derive(arbitrary::Arbitrary) on our structured input types to generate a pseudorandom instance of Module, unconstrained by validity. The module’s instruction sequence is almost certainly not valid at this point: it likely is missing operands for instructions, producing more results than the function’s signature describes, producing results of types that don’t match the function signature, accessing globals and locals that don’t exist, etc… Having produced an instance of Module, it next calls the Module::fixup method to mutate the Module so that it is valid.

The fixup method works by abstractly interpreting the instruction sequence to track the types of each value on the stack at every program point. Whenever an instruction’s operand types don’t match the types on top of the stack, it generates dummy values of the correct type. When the instructions produce more values than the function’s signature proscribes, it emits drop instructions.

impl Module {
    pub fn fixup(&mut self, mut make_value: impl FnMut() -> i64) {
        // ...

        // The fixed-up instructions.
        let mut fixed = Vec::with_capacity(
            self.instructions.len(),
        );

        // The types on the stack at any given program
        // point. Similar to the Wasm spec's appendix's
        // validation algorithm.
        let mut stack: Vec<ValType> = Vec::new();

        for inst in mem::take(&mut self.instructions) {
            // Special-case `drop` because it is
            // polymorphic.
            if matches!(inst, Inst::Drop) {
                if stack.is_empty() {
                    fixed.push(
                        ValType::I32.make_const(make_value()),
                    );
                } else {
                    stack.pop();
                }
                fixed.push(inst);
                continue;
            }

            // First clamp entity indices to valid
            // ranges.
            let Some(inst) = self.fixup_inst_immediates(
                &mut make_value,
                has_mutable_global,
                inst,
            ) else {
                continue
            };

            // Then make sure that the stack has
            // operands of the correct types for this
            // instruction.
            self.fixup_stack(
                &mut make_value,
                &mut fixed,
                &mut stack,
                &inst,
            );

            // Finally, apply the effects to the stack.
            let len_operands = inst.operand_types(
                &self.globals,
            ).len();
            stack.truncate(stack.len() - len_operands);
            stack.extend(inst.result_type(
                &self.param_types,
                &self.globals,
            ));

            fixed.push(inst);
        }

        // ...

        self.instructions = fixed;
    }

    fn fixup_stack(
        &mut self,
        mut make_value: impl FnMut() -> i64,
        fixed: &mut Vec<Inst>,
        stack: &mut Vec<ValType>,
        inst: &Inst,
    ) {
        let needed = inst.operand_types(&self.globals);
        let n = needed.len();

        if stack.len() >= n {
            if (0..n).all(|i| {
                stack[stack.len() - n + i] == needed[i]
            }) {
                // All needed operands are on the stack.
                return;
            }
        } else {
            if stack.iter().enumerate().all(|(i, ty)| {
                *ty == needed[i]
            }) {
                // A prefix of needed operands are on the
                // stack; make constants for the tail that
                // are missing.
                for ty in &needed[stack.len()..] {
                    fixed.push(ty.make_const(make_value()));
                    stack.push(*ty);
                }
                return;
            }
        }

        // Otherwise, just make constants for all the
        // needed operands.
        for ty in needed {
            fixed.push(ty.make_const(make_value()));
            stack.push(*ty);
        }
    }

    // ...
}

The fixup method also makes sure that for all instructions that have an immediate referencing some entity, the referenced entity is valid. For example, for a local.get $l instruction, it ensures that local $l actually exists or else rewrites the local to one that does exist.

impl Module {
    // ...

    fn fixup_inst_immediates(
        &mut self,
        mut make_value: impl FnMut() -> i64,
        has_mutable_global: bool,
        mut inst: Inst,
    ) -> Option<Inst> {
        match &mut inst {
            Inst::LocalGet(l) => *l %= self.param_types.len() as u32,

            // ...

            Inst::I32Load(m)
            | Inst::I64Load(m)
            | Inst::F32Load(m)
            | Inst::F64Load(m)
            | Inst::V128Load(m) => {
                if self.num_memories == 0 {
                    return None;
                }
                *m %= self.num_memories;
            }

            // ...

            _ => {}
        }

        Some(inst)
    }
}

After calling fixup, the arb generator invokes Module::to_wasm_binary to get the encoded Wasm program.

bottom_up

The bottom_up generator also uses abstract interpretation to track the types of values on the stack. It generates instructions in forwards order, from operands to operators. It begins with an empty stack, filters candidate instructions down to just those that would be valid given the types currently on the stack, randomly chooses one, updates the stack types accordingly, and repeats the process. This is the same approach that wasm-smith uses. After generating instructions this way, it then makes sure that the final types on the stack match the function signature’s results, similar to the end of fixup.

impl Module {
    pub fn bottom_up(u: &mut Unstructured<'_>) -> Result<Self> {
        // ...

        let max_insts = u.int_in_range(1..=MAX_INSTS)?;
        let mut instructions = Vec::new();
        let mut stack: Vec<ValType> = Vec::new();

        for _ in 0..max_insts {
            if stack == result_types && u.ratio(3, 4)? {
                break;
            }

            // Choose a random instruction whose operand
            // types match those currently on the stack.
            let inst = choose_inst_bottom_up(
                u,
                &stack,
                &param_types,
                &globals,
                num_memories,
            )?;

            // Apply this instruction's effects to the
            // stack.
            apply_inst(
                &inst,
                &mut stack,
                &param_types,
                &globals,
            );
            instructions.push(inst);
        }

        // ...

        Ok(Module {
            param_types,
            result_types,
            globals,
            num_memories,
            instructions,
        })
    }
}

fn choose_inst_bottom_up(
    u: &mut Unstructured<'_>,
    stack: &[ValType],
    param_types: &[ValType],
    globals: &[Global],
    num_memories: u32,
) -> Result<Inst> {
    // Build up all the valid candidate instructions.
    let mut candidates: Vec<Inst> = Vec::new();

    // Producers are always okay: [] -> [t]
    candidates.push(Inst::I32Const(0));
    candidates.push(Inst::I64Const(0));
    candidates.push(Inst::F32Const(0.0));
    candidates.push(Inst::F64Const(0.0));
    candidates.push(Inst::V128Const(0));
    if !param_types.is_empty() {
        candidates.push(Inst::LocalGet(0));
    }

    // ...

    let top = stack.last().copied();
    let second = stack.get(stack.len() - 2).copied();

    // Drop needs 1 operand of any type: [t] -> []
    if top.is_some() {
        candidates.push(Inst::Drop);
    }

    // i32 unary: [i32] -> [...]
    if top == Some(I32) {
        candidates.push(Inst::I32Clz);
        candidates.push(Inst::I32Ctz);
        candidates.push(Inst::I32Popcnt);
        // ...
    }

    // i64 unary: [i64] -> [...]
    if top == Some(I64) {
        candidates.push(Inst::I64Clz);
        candidates.push(Inst::I64Ctz);
        candidates.push(Inst::I64Popcnt);
        // ...
    }

    // ...

    // i32 binary: [i32 i32] -> [...]
    if top == Some(I32) && second == Some(I32) {
        candidates.push(Inst::I32Add);
        candidates.push(Inst::I32Sub);
        candidates.push(Inst::I32Mul);
        // ...
    }

    // i64 binary: [i64 i64] -> [...]
    if top == Some(I64) && second == Some(I64) {
        candidates.push(Inst::I64Add);
        candidates.push(Inst::I64Sub);
        candidates.push(Inst::I64Mul);
        // ...
    }

    // ...

    // Choose a random instruction from the
    // candidates.
    let mut inst = *u.choose(&candidates)?;

    // If the instruction has immediates, generate
    // them here, as they were hard-coded during
    // candidate selection.
    match &mut inst {
        Inst::I32Const(v) => *v = u.arbitrary()?,
        Inst::I64Const(v) => *v = u.arbitrary()?,
        // ...
        Inst::GlobalGet(g) => {
            *g = u.int_in_range(0..=(globals.len() as u32 - 1))?;
        }
        // ...
        Inst::I32Load(m)
        | Inst::I64Load(m)
        | Inst::F32Load(m)
        | Inst::F64Load(m)
        | Inst::V128Load(m)
        | Inst::I32Store(m)
        | Inst::I64Store(m)
        | Inst::F32Store(m)
        | Inst::F64Store(m)
        | Inst::V128Store(m)
        | Inst::MemorySize(m)
        | Inst::MemoryGrow(m) => {
            *m = u.int_in_range(0..=(num_memories - 1))?;
        }
        _ => {}
    }

    Ok(inst)
}

After constructing a Module via bottom_up, we don’t need to call fixup because the module is already valid by construction, so all that’s left is invoking Module::to_wasm_binary to get the encoded Wasm program.

top_down

The top_down generator is very similar to bottom_up, but instead of generating instructions forwards, from operands to operators, it generates them backwards, from operators to operands. Instead of maintaining a stack of the types of values generated thus far by the instruction sequence prefix, it maintains a stack of the types of values expected by the instruction sequence suffix. This is the approach that rgfuzz by Park, Kim, and Yun takes.²

impl Module {
    pub fn top_down(
        u: &mut Unstructured<'_>,
    ) -> Result<Self> {
        // ...

        let max_insts = u.int_in_range(1..=MAX_INSTS)?;
        let mut instructions = Vec::new();
        let mut needed = result_types.clone();
        for _ in 0..max_insts {
            if needed.is_empty() && u.ratio(3, 4)? {
                break;
            }

            // Choose a random instruction in a
            // top-down manner.
            let inst = choose_inst_top_down(
                u,
                needed.last().copied(),
                &param_types,
                &globals,
                num_memories,
            )?;

            // Pop the result type from `needed`, if
            // any, as it's been satisfied.
            let ty = inst.result_type(
                &param_types,
                &globals,
            );
            if ty == needed.last().copied() {
                needed.pop();
            }

            // Add operand type demands.
            match &inst {
                Inst::Drop => {
                    // `drop` is polymorphic; choose
                    // a random type.
                    needed.push(u.arbitrary()?);
                }
                Inst::GlobalSet(g) => {
                    needed.push(globals[*g as usize].ty);
                }
                _ => {
                    needed.extend_from_slice(
                        inst.operand_types(&globals),
                    );
                }
            }

            instructions.push(inst);
        }

        // Fill remaining needed types with
        // constants.
        for ty in needed.iter().rev() {
            instructions.push(
                ty.make_const(u.arbitrary()?),
            );
        }

        // Instructions were generated backwards, so
        // reverse.
        instructions.reverse();

        Ok(Module {
            param_types,
            result_types,
            globals,
            num_memories,
            instructions: prefix,
        })
    }
}

fn choose_inst_top_down(
    u: &mut Unstructured<'_>,
    target_ty: Option<ValType>,
    param_types: &[ValType],
    globals: &[Global],
    num_memories: u32,
) -> Result<Inst> {
    let mut candidates: Vec<Inst> = Vec::new();
    match target_ty {
        Some(I32) => {
            candidates.push(Inst::I32Const(0));
            candidates.push(Inst::I32Add);
            candidates.push(Inst::I32Sub);
            candidates.push(Inst::I32Mul);
            // ...
        }
        Some(I64) => {
            candidates.push(Inst::I64Const(0));
            candidates.push(Inst::I64Add);
            candidates.push(Inst::I64Sub);
            candidates.push(Inst::I64Mul);
            // ...
        }
        Some(F32) => {
            candidates.push(Inst::F32Const(0.0));
            candidates.push(Inst::F32Add);
            candidates.push(Inst::F32Sub);
            candidates.push(Inst::F32Mul);
            // ...
        }
        // ...
        None => {
            // Nothing needed. `drop`, `global.set`, and
            // stores add demand.
            candidates.push(Inst::Drop);
            if globals.iter().any(|g| g.mutable) {
                candidates.push(Inst::GlobalSet(0));
            }
            if num_memories > 0 {
                candidates.push(Inst::I32Store(0));
                // ...
            }
        }
    }

    let mut inst = *u.choose(&candidates)?;

    // If the instruction has immediates, generate
    // them here, as they were hard-coded during
    // candidate selection. Same as `bottom_up`.
    match &mut inst {
        // ...
    }

    Ok(inst)
}

Similar to bottom_up, after we’ve constructed a Module via top_down, we don’t need to call fixup because the module is already valid by construction. All that’s left is invoking Module::to_wasm_binary to get the encoded Wasm program.

mutate

mutate is, as the name implies, a mutator rather than a generator. It is the direct equivalent of the arb generator, but for mutation: it uses derive(mutatis::Mutate) on Module and Inst to automatically generate custom mutators for these types, rather than authoring them by hand. After producing a new Module by mutating an old Module, that new Module probably represents an invalid Wasm program, in the same way that derive(arbitrary::Arbitrary) produces Modules that are probably invalid. And mutate also uses the same approach that arb does to resolve this problem: the fixup method.

But first, a mutator-specific wrinkle is that fuzz_mutator! gives us a mutable byte slice to mutate, not a Module. We address this gap by deriving the serde crate’s Serialize and Deserialize traits on Module and Inst, deserializing a Module from the mutable byte slice, mutating that deserialized Module with mutatis, and then reserializing it back into the mutable byte slice. We use the postcard crate here, but could just as easily use bincode, JSON, or protobuf.

use libfuzzer_sys::{fuzz_mutator, fuzz_target, fuzzer_mutate};

fuzz_mutator!(|
    data: &mut [u8],
    size: usize,
    max_size: usize,
    seed: u32,
| {
    // With probability of about 1/8, use default
    // mutator.
    if seed.count_ones() % 8 == 0 {
        return fuzzer_mutate(data, size, max_size);
    }

    // Try to decode using postcard; fallback to
    // default input on failure.
    let mut module: Module =
        postcard::from_bytes(&data[..size])
            .ok()
            .unwrap_or_default();

    // Mutate with `mutatis`.
    let mut session = mutatis::Session::new()
        .seed(seed.into())
        .shrink(max_size < size);
    if session.mutate(&mut module).is_ok() {
        if let Ok(encoded) = postcard::to_slice(
            &module,
            data,
        ) {
            return encoded.len();
        }
    }

    // Fallback to the default libfuzzer mutator if
    // serialization or mutation fails because, for
    // example, `data` doesn't have enough capacity.
    fuzzer_mutate(data, size, max_size)
});

Finally, the fuzz target itself deserializes the Module from the raw bytes, calls fixup, encodes it to a Wasm binary via Module::to_wasm_binary, and then passes that into Wasmtime.

fuzz_target!(|data: &[u8]| {
    let Ok(mut module) = postcard::from_bytes::<Module>(data) else {
        return;
    };
    module.fixup(|| 0);
    let wasm = module.to_wasm_binary();

    // ...
});

Benchmarking

Methodology

We pair each of our generators and mutator with libfuzzer-sys and feed the resulting test cases into Wasmtime. All fuzzers start with an empty corpus.

The most important metric for a fuzzer is its bug-finding ability, but that can be difficult to measure directly. For example, Wasmtime is actively fuzzed 24/7 with more-complete fuzzers than those implemented here, so, as expected, I have not found any bugs via these benchmarks. Therefore, instead of reporting a found-bugs count, the benchmark harness reports two alternative metrics:

1. Coverage over time: Coverage is the cumulative code paths exercised by the fuzzer. A fuzzer cannot find bugs in code paths it does not cover. This is the most important metric reported.

2. Executions over time: An execution is one iteration of the fuzzing loop. This is basically measuring how fast the fuzzer can produce test cases. All else being equal, more executions is better, but all else is rarely equal. It is easy to generate poor test cases very quickly: just return an empty sequence of Wasm instructions every time. Unfortunately, that exclusively leads to useless executions. Therefore, this metric is really only useful when comparing two implementations of the same algorithm, and I’ve omitted its results in the next section.

Additionally, I report results for both 24 hours of fuzzing and 5 minutes of fuzzing. The expected behavior of long-term fuzzing, e.g. 24/7 fuzzing in OSS-Fuzz, can be extrapolated from the 24-hour results. The 5-minute results show the expected behavior of short-term fuzzing, e.g. when using mutatis::check or arbtest.

Discussion of short-term fuzzing is somewhat rare, so I feel its motivation deserves explanation. I find short-term fuzzing useful in the following scenarios, for example:

• Running a quick fuzzing session locally, to catch bugs that avoid detection in the traditional unit- and integration-test suites, before opening a pull request.
• Running some quick fuzzing in CI before allowing a pull request to merge, for similar reasons.

That is, short-term fuzzing is useful for the same reasons and in the same scenarios as property-based testing.³

As recommended in Evaluating Fuzz Testing by Klees, Ruef, Cooper, Wei, and Hicks and adopted in Fuzz Bench: An Open Fuzzer Benchmarking Platform and Service by Metzman, Szekeres, Simon, Sprabery, and Arya, the benchmark harness tests the statistical significance of its results with a Mann-Whitney U-test. The harness performs 20 trials per fuzzer, the same number of trials as Fuzz Bench.

Results

24 Hours of Fuzzing

• arb has 1.00 ± 0.00 times more coverage than bottom_up (p = 0.01)

• mutate has 1.01 ± 0.00 times more coverage than arb (p = 0.00)

• top_down has 1.00 ± 0.00 times more coverage than arb (p = 0.00)

• mutate has 1.02 ± 0.00 times more coverage than bottom_up (p = 0.00)

• top_down has 1.01 ± 0.00 times more coverage than bottom_up (p = 0.00)

• mutate has 1.01 ± 0.00 times more coverage than top_down (p = 0.00)

5 Minutes of Fuzzing

• bottom_up has 1.01 ± 0.01 times more coverage than arb (p = 0.04)

• mutate has 1.47 ± 0.02 times more coverage than arb (p = 0.00)

• top_down has 1.06 ± 0.02 times more coverage than arb (p = 0.00)

• mutate has 1.45 ± 0.01 times more coverage than bottom_up (p = 0.00)

• top_down has 1.05 ± 0.02 times more coverage than bottom_up (p = 0.00)

• mutate has 1.38 ± 0.02 times more coverage than top_down (p = 0.00)

Conclusion

The mutate fuzzer performs best. It vastly outperforms all the others at 5 minutes of fuzzing (36-49% more coverage), and while the rest narrow that gap after 24 hours of fuzzing, mutate maintains its lead (1-2% more coverage).

The comparison between arb and mutate is as apples-to-apples of a comparison as it gets between idiomatic test-case generation and mutation in Rust: derive(Arbitrary) and derive(Mutate). They use the same fixup method to ensure that the resulting Wasm instructions are valid. The fuzzer built with mutatis and test-case mutation provides better coverage over time than the fuzzer built with arbitrary and test-case generation. When writing structure-aware fuzzers, I used to reach for arbitrary; in the future, I will reach for mutatis instead.

The top_down fuzzer performs second-best, and is best of the generation-based fuzzers. This aligns with results from the rgfuzz paper, which found that top-down Wasm instruction generation resulted in better instruction diversity than bottom-up generation. This result is intuitive, they point out, because Wasm instructions tend to have more operands than results, which means that more candidates are filtered out from consideration when generating instructions in forward order from operands to results (bottom-up) than when generating them in backward order from results to operands (top-down).

Subjectively, none of the approaches feel significantly more-complicated nor easier to implement than the others. All approaches require a stack of types, representing the generated Wasm’s operand stack, at some point in their implementation. Some require it during instruction generation (top_down and bottom_up) while others require it during fixup (mutate and arb). Adding support for new Wasm instructions is roughly the same in all of them: add a new variant to enum Inst and define its operand and result types. top_down and bottom_up additionally require adding a line for the new instruction in their choose_inst_{top_down,bottom_up} functions, but this could be avoided with some targeted macro_rules! sugar.

The fixup method fixes instructions in a forwards order; as future work, it would be interesting to implement a backwards_fixup method that fixes instructions in a backwards order and see if mutate and backwards_fixup outperforms the current mutate and forwards fixup the same way that backwards generation (top_down) outperforms forwards generation (bottom_up).

fixup makes an attempt to reuse stack operands when it can, rather than synthesize dummy constants or drop already-computed values, but the attempt is somewhat half-hearted. Dropping operands introduces dead code, which is not very interesting for exercising deep into the compiler pipeline. Dummy constants are not that interesting either. Therefore, another potential line of follow-up work would be to investigate ways to maximize operand reuse and minimize drops and dummy constants inserted while ensuring validity. That could include storing values to memory or globals instead of droping them when possible. It could even include liberating ourselves from the stack-focused paradigm we’ve had thus far.

WebAssembly is a stack-based language and so it is natural that our approaches have focused on producing stack-y code. But, in practice, optimizing WebAssembly compilers like Wasmtime’s use a static single-assignment intermediate representation, and erase the operand stack early in their compilation pipelines. Therefore, from these compilers’ point of view, the following two WebAssembly snippets are identical:

;; `x = a + (b * c)` in a "stack-y" encoding and
;; without temporary locals.
local.get $a
local.get $b
local.get $c
i32.mul
i32.add
local.set $x

;; `x = a + (b * c)` in a "non-stack-y" encoding
;; that uses temporary locals for every operation.
;;
;; Equivalent of
;;
;;     temp0 = b * c
;;     temp1 = a + temp0
;;     x = temp1
local.get $b
local.get $c
i32.mul
local.set $temp0
local.get $a
local.get $temp0
i32.add
local.set $temp1
local.get $temp1
local.set $x

Producing code that uses many temporaries in this manner might be easier than code that doesn’t, but, more importantly, it may enable better reuse of already-computed subexpressions, emit less dead code, and ultimately produce more interesting data-flow graphs that better exercise the deep innards of the compiler.

A final vein of interesting follow-up work to mine would be comparing arbitrary-based generators and mutatis-based mutators for structured inputs that are not programming languages and when the SUT we are fuzzing is not a compiler. Do we see these same results when, for example, producing PNG images to fuzz an image-transformation library?

Here is the source code for this experiment, including the three generators, one mutator, raw benchmark data, and benchmarking harness. The README includes instructions on running the benchmarks yourself.

Language

• Allow passing expr metavariable to cfg
• Always coerce never types in tuple expressions
• Avoid incorrect inference guidance of function arguments in rare cases
• Support s390x vector registers in inline assembly
• Allow using constants of type ManuallyDrop as patterns (fixing a regression introduced in 1.94.0)

Compiler

• Enable link relaxation feature for LoongArch Linux targets
• Update riscv64gc-unknown-fuchsia baseline to RVA22 + vector

Libraries

• Support iterating over ranges of NonZero integers
• refactor 'valid for read/write' definition: exclude null; add that as an exception on individual methods instead
• Fix SGX delayed host lookup via ToSocketAddr

Stabilized APIs

• assert_matches!
• debug_assert_matches!
• From<T> for AssertUnwindSafe<T>
• From<T> for LazyCell<T, F>
• From<T> for LazyLock<T, F>
• core::range::RangeToInclusive
• core::range::RangeToInclusiveIter
• core::range::RangeFrom
• core::range::RangeFromIter
• core::range::Range
• core::range::RangeIter

Cargo

• Allow a dependency to specify both a git repository and an alternate registry. Just like with crates.io, the git repository will be used locally, but the registry version will be used when published.
• Added target.'cfg(..)'.rustdocflags support in configuration.
• Fixed CVE-2026-5222 and CVE-2026-5223.

Rustdoc

• Deprecation notes are now rendered like any other documentation. Previously they used the css white-space: pre-wrap; property and stripped any <p> elements from the rendered html, however this caused issues and unintuitive behavior. The new behavior should be more predictable, however some multi-line deprecation notes will now be rendered as as single lines. If this is undesirable, you can use the standard markdown method of forcing a linebreak, which is two spaces followed by a newline ("\n").
• Don't emit rustdoc missing_doc_code_examples lint on impl items
• Seperate methods and associated functions in sidebar

Compatibility Notes

• Fix layout of #[repr(Int)] enums in some edge cases involving fields of uninhabited zero-sized types
• Prevent unsize-coercing into Pin<Foo> where Foo doesn't implement Deref. Some such coercions were previously allowed, but produce a type with no useful public API.
• rustc: Stop passing --allow-undefined on wasm targets
• Gate the accidentally stabilized #![reexport_test_harness_main] attribute
• Error on return-position-impl-trait-in-traits whose types are too private
• Report the uninhabited_static lint in dependencies and make it deny-by-default
• Distributed builds now contain non-split debuginfo for windows-gnu This appears to improve the quality of backtraces. This change has no effect on the defaults for the output of rustc/cargo on these targets.
• Check const generic arguments are correctly typed in more positions
• Remove -Csoft-float
• Importing structs with ::{self [as name]}, e.g., struct S {}; use S::{self as Other};, is now no longer permitted because {self} imports require a module parent.
• For export_name, link_name, and link_section attributes, if multiple of the same attribute is present, the first one now takes precedence.
• Update the minimum external LLVM to 21
• On avr targets, C's double type is 32-bit by default, so change c_double to f32 on avr targets to match. This is a breaking change, but necessary to make c_double match C's double.

Internal Changes

These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools.

• JSON targets: aarch64 softfloat targets now have to have rustc_abi set to "softfloat"
• target specs: stricter checks for LLVM ABI values, and correlate that with cfg(target_abi)

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.

Updates from Rust Community

Newsletters

• Scientific Computing in Rust #18 (May 2026)

Project/Tooling Updates

• gitoxide - May 26
• hyper User Survey 2025 Results
• Rust Update: gRPC Welcomes Tonic!
• serde-const-default v0.1: Removes boilerplate when using const values as field defaults
• BoquilaHUB 0.5: AIs for Nature. Now it includes SOTA AI bioacoustics models and embeddings models
• splog: a log viewer TUI with automatic tag categorization
• rgx v0.12.3 — Building a regex debugger for the terminal in Rust
• UI tests are the guardrails an AI needs: the story of clipboardwire
• slintcn 0.22: shadcn/ui-style copy-paste components for Slint native apps
• Releasing dtact v0.2.2 and rssn-advanced v0.1.0: the next generation async concurrent engine and scientific computing engine

Observations/Thoughts

• Noroboto: Lying Fonts and Mitigation in Rust
• Erasing Existentials
• libwce: the entropy layer of a wavelet codec, on its own
• Tech Notes: Theseus: translating win32 to wasm
• Bevy Game Engine Explained Visually
• The reflex of deriving serde traits
• Physical AI Needs a Typed World Model, Not a Vector DB
• Keep calm and use (Rust) monorepos
• [audio] Rust for Linux Live with Alice Ryhl and Greg Kroah-Hartman
• [audio] Netstack.FM episode 38 — Building and testing network stacks with Rama
• [video] Can a QR code be made of stars?

Rust Walkthroughs

• Rust Patterns & Engineering How-Tos
• Laissez-Faire Errors
• Learn Rust HashMap and Iterators by Building a Git Object Store Reader
• Learn the Basics of Bevy by Building and Deploying Pong to Itch.io
• The Slowdown That Doesn't Show Up in Profiles
• Building an AsyncIO executor for the 3DS
• [video] Nine Ways to do Inheritance in Rust, a Language without Inheritance

Miscellaneous

• Content-addressed Rust builds (or, what kache actually caches)

Crate of the Week

This week's crate is inline_tweak, a crate to embed tweakable constants inside your Rust application without full recompilation.

Thanks to Kill The Mule for the suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.

If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs.

Let us know if you would like your feature to be tracked as a part of this list.

Call for Participation; projects and speakers

CFP - Projects

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

• rust cookbook - Expand Command Line section with clap derive, subcommands, and env vars

If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon!

CFP - Events

Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.

• No Calls for papers or presentations were submitted this week.

If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon!

Updates from the Rust Project

352 pull requests were merged in the last week

Compiler

• rustc_on_unimplemented: introduce format specifiers
• account for proc macro spans in do_not_recommend diagnostics
• implement fast path for derive(PartialOrd) when deriving Ord
• make bitset would_modify_words more vectorzer-friendly
• parse mut restrictions
• stop needing materialized places for most intrinsics

Library

• add unstable Share trait
• stabilize bool_to_result
• use strongly typed wrapped indices in VecDeque

Cargo

• compiler: forward verbose flag to rustc for local crates
• don't use the network for a publish dry-run test
• break out RegistryConfig and crate_url for interpreting RegistryConfig::dl
• fix CVE-2026-5222 and CVE-2026-5223
• artifact: remove compat mode from artifacts

Rustdoc

• stabilize --remap-path-prefix in rustdoc

Clippy

• useless_format: fire on wrapped in a block-producing macro
• return can be removed from the last stmt of a block if it has an expr
• add check for midpoint using multiplication by 0.5 and >> 1
• avoid unnecessary String allocations in MinifyingSugg arithmetic ops
• extend clippy::missing_safety_doc to unsafe fields
• fix manual_range_contains NAN handling
• fix error message for useless_borrows_in_formatting for mutable borrows
• move unnecessary_get_then_check to complexity
• simplify is_some() && …unwrap() to is_some_and in unit_arg

Rust-Analyzer

• diagnostics: mut_ref binding feature diagnostic
• assists/add_reference_here: _modify_ the reference type when dealing with &T->&mut T
• cfg: correct separator index in CfgDiff disable loop
• hir-ty: saturate float-to-uint cast in const eval
• test-utils: drain inactive_regions by inactive_line_region
• add diagnostic for E0033
• add diagnostic for E0608
• completions imports exclude supports sub items
• filter package-scoped features
• extract_module missing import for macro calls
• add type_match score for struct_pat
• allow wildcard params in foreign fn declarations
• analysis expected ty in enum variant
• autoimport enum variants
• do not autoref in method probe in path mode
• do not complete semicolon in match-expr place
• do not consider the path of the macro in a macro call to be inside a macro call
• emit diagnostic for rest array patterns without fixed-length arrays
• fix SyntaxContext::roots technically overlapping valid interneds
• flip coerce_never type_mismatch tys
• have a specific error for unimplemented builtin macros
• no suggest ref match when expected generic ref
• no use sad pattern on happy arm with guard
• normalize expected tuple struct pat field
• refactor handling of generic params in hir::Type
• support named consts in range pattern types
• use grouped annotation for add_label_to_loop
• provide better incrementality for modules

Rust Compiler Performance Triage

This week was largely positive, with most of the improvements coming from algorithm change in visibility checking: #156228.

Triage done by @panstromek. Revision range: 281c97c3..783eb8c8

Summary:

2 Regressions, 2 Improvements, 5 Mixed; 2 of them in rollups 34 artifact comparisons made in total

Full report here

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

• Propose the concept of a crates.io username for identity

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

Tracking Issues & PRs

• Promotes 5 Thumb-mode bare-metal Arm targets to Tier 2
• Add -Z dead-fn-elimination to skip codegen of BFS-unreachable functions

• Update transmute_copy to ub_checks and ?Sized
• Tracking Issue for NEON dot product intrinsics
• Never break between empty parens

• Avoid linting unreachable_code on todo!()

• What are the values of a union type? (in particular, what is the validity invariant of a union)

No Items entered Final Comment Period this week for Cargo, Language Team, Language Reference or Leadership Council. Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.

New and Updated RFCs

• No New or Updated RFCs were created this week.

Upcoming Events

Rusty Events between 2026-05-27 - 2026-06-24 🦀

Virtual

• 2026-05-27 | Virtual (Girona, ES) | Rust Girona
  • Weekly coding session
• 2026-06-02 | Virtual | libp2p Events
  • rust-libp2p Open Maintainers Call
• 2026-06-02 | Virtual (Tel Aviv-yafo, IL) | Rust 🦀 TLV
  • ‎שיחה חופשית ווירטואלית על ראסט
• 2026-06-03 | Virtual (Indianapolis, IN, US) | Indy Rust
  • Indy.rs - with Social Distancing
• 2026-06-04 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-06-04 | Virtual (Nürnberg, DE) | Rust Nuremberg
  • Rust Nürnberg online
• 2026-06-04 | Virtual (Tel Aviv-yafo, IL) | Code Mavens 🦀 - 🐍 - 🐪
  • Exploring FalkorDB - Learning to use a Graph Database in Rust
• 2026-06-06 | Virtual (Kampala, UG) | Rust Circle Meetup
  • Rust Circle Meetup
• 2026-06-07 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: First Sunday
• 2026-06-09 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Second Tuesday
• 2026-06-10 | Virtual (Girona, ES) | Rust Girona
  • Weekly coding session
• 2026-06-16 | Virtual (Washington, DC, US) | Rust DC
  • Mid-month Rustful
• 2026-06-17 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Jiff
• 2026-06-17 | Virtual (Girona, ES) | Rust Girona
  • Weekly coding session
• 2026-06-18 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • June, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-06-18 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-06-21 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: Third Sunday
• 2026-06-23 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Fourth Tuesday
• 2026-06-23 | Virtual (London, UK) | Women in Rust
  • Lunch & Learn: What the heck are monads - and how do we fake them in Rust

Asia

• 2026-06-02 | Beijing, CN | Voice AI and Rust Meetup (Rust for AI, lowcoderust.com)
  • AI Agents and Open Source LLM (Call for Speakers)

Europe

• 2026-05-28 | Copenhagen, DK | Copenhagen Rust Community
  • Rust meetup #68
• 2026-05-28 | London, UK | Rust London User Group
  • LDN Talks May Community Showcase
• 2026-05-29 | Berlin, DE | Rust Berlin
  • Rust Berlin Talks: The next generation
• 2026-05-30 | Stockholm, SE | Stockholm Rust
  • Ferris' Fika Forum #26
• 2026-06-02 | Frankfurt, DE | Rust Rhein-Main
  • gRPC with Rust and Tonic
• 2026-06-03 | Dublin, IE | Rust Dublin
  • Join us live and INPERSON for Rust 261
• 2026-06-03 | Girona, ES | Rust Girona
  • Rust Girona Hack & Learn 06 2026
• 2026-06-10 | München, DE | Rust Munich
  • Rust Munich 2026 / 2 - Hacking Evening
• 2026-06-11 | Switzerland, CH | PostTenebrasLab
  • Rust Meetup Geneva
• 2026-06-12 - 2026-06-14 | Kraków, PL | Rustmeet
  • Rustmeet
• 2026-06-16 | Leipzig, DE | Rust - Modern Systems Programming in Leipzig
  • Interactive: Everything is Open Source
• 2026-06-16 | Milano, IT | Rust Language Milan
  • Real-time planning in Rust: SolverForge & SERIO
• 2026-06-18 | Aarhus, DK | Rust Aarhus
  • Talk Night at Danske Commodities

North America

• 2026-05-27 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground
• 2026-05-28 | Atlanta, GA, US | Rust Atlanta
  • Rust-Atl
• 2026-05-28 | Los Angeles, CA, US | Rust Los Angeles
  • Rust LA: Rust in Embedded & Autonomous Systems at Parallel Systems in DTLA
• 2026-05-28 | Mountain View, CA, US | Hacker Dojo
  • RUST MEETUP at HACKER DOJO
• 2026-05-30 | Boston, MA, US | Boston Rust Meetup
  • Central Cambridge Rust Lunch, May 30
• 2026-06-04 | Saint Louis, MO, US | STL Rust
  • Testing, Coverage, Tracey & Mutations
• 2026-06-06 | Boston, MA, US | Boston Rust Meetup
  • Boston Common Rust Lunch, June 6
• 2026-06-11 | Lehi, UT, US | Utah Rust
  • Utah Rust June Meetup
• 2026-06-11 | Mountain View, CA, US | Hacker Dojo
  • RUST MEETUP at HACKER DOJO
• 2026-06-11 | San Diego, CA, US | San Diego Rust
  • San Diego Rust June Meetup - Back in person!
• 2026-06-16 | San Francisco, CA, US | San Francisco Rust Study Group
  • Rust Hacking in Person
• 2026-06-17 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Jiff
• 2026-06-18 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • June, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-06-24 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground
• 2026-06-24 | Los Angeles, CA, US | Rust Los Angeles
  • Rust LA: Rust-Based Constraint Solvers in 2D Sketching with Zoo Technologies

South America

• 2026-06-18 | Florianópolis, BR | Rust SC
  • Rust Floripa

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

This overflows the trait solver today as well as my brain

– Nadrieril on their blog

Thanks to Theemathas for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by:

• nellshamrell
• llogiq
• ericseppanen
• extrawurst
• U007D
• mariannegoldin
• bdillo
• opeolluwa
• bnchi
• KannanPalani57
• tzilist

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

Highlights:

• [Markus Stange] Use @streamparser/json if the input is too large to fit in a V8 string (#6016)
• [Nazım Can Altınova] Include --search option in pq filter push (#6026)
• [fatadel] Translate URL track-index state through profile sanitization (#6000)
• [Nazım Can Altınova] Print also the status output right after cli load command (#6019)

Other Changes:

• [fatadel] Remove unused dependencies from package.json (#6010)
• [Nazım Can Altınova] Make profiler-cli work in sandboxed environments (#6003)
• [Markus Stange] Make profiler-edit run profile compacting before writing out the file (#6015)
• [Markus Stange] Migrate from prettier to oxfmt (#5986)
• [Markus Stange] Add a --symbolicate-wasm arg to profiler-edit. (#6008)
• [Markus Stange] Build and upload the cli artifact in PRs (#6020)
• [Nicolas Chevobbe] Update devtools-reps to 0.27.7 (#6030)
• [Markus Stange/fatadel] Make withSize use a wrapper element so that it can stop calling findDOMNode (#5988)
• [Markus Stange] Fix dhat importer (#6036)
• [Nazım Can Altınova] Annotate inlined frames in CLI call trees and stacks (#6041)
• [Nazım Can Altınova] Use proper types in cli tests instead of custom inline types (#6038)
• [Nazım Can Altınova] Fix text truncation for frames named after Object.prototype methods (#6044)
• [Nazım Can Altınova] Add missing key props to CodeErrorOverlay error list items (#6047)
• [depfu[bot]] Update oxfmt to version 0.51.0 (#6054)
• [Nazım Can Altınova] Sync: l10n → main (May 26, 2026) (#6058)
• [Nazım Can Altınova] Use URL-state symbol server for profiler-cli function annotate (#6051)
• [Nazım Can Altınova] Bump profiler-cli version to 0.2.0 (#6059)

Big thanks to our amazing localizers for making this release possible:

• fr: YD
• sr: Марко Костић (Marko Kostić)
• tr: Ali Demirtaş
• zh-CN: Olvcpr423
• zh-CN: wxie

Find out more about the Firefox Profiler on profiler.firefox.com! If you have any questions, join the discussion on our Matrix channel!

1 post - 1 participant

Read full topic

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.

Updates from Rust Community

Official

• Project goals update — April 2026 (end of 2025H2)
• Program management update — April 2026

Newsletters

• This Month in Rust OSDev: April 2026

Project/Tooling Updates

• Tonic is joining the gRPC project
• Toasty 0.6.0 - What is new?
• ex_ratatui: Elixir bindings for ratatui via Rustler NIFs
• OmniScope: A Cross-Language LLVM IR Static Analyzer Targeting Unsafe/FFI Boundaries:
• citum: a new Rust citation processor and associated tools.
• cargo-crap: Finding Untested Complexity in AI-Generated Rust Code
• What the Graph Owes: Connectors That Drive Outputs
• swpui: a TUI for case-aware search and replace
• kache 0.3.0: zero-copy efficient worktree compilation
• ghr: a Rust TUI for managing GitHub pull requests, issues, notifications, and reviews

Observations/Thoughts

• Scaling Rust codebases: Lessons learned organizing large projects and managing errors
• Migrating from Go to Rust
• Why I built wrkflw
• [video] Rust's God Mode
• [video] How Rust engineered the perfect async runtime

Rust Walkthroughs

• 5× faster fast_blur in image-rs
• Finding the Time Part 2 - Rust Async and the Arm Generic Timer
• Parsing Godot .tres files and walking the resource graph
• Rust x GBA: Setup and Pixels
• Learn Rust Lifetimes by Building a Generic LRU Cache
• How to benchmark Rust code with Gungraun
• Book: An Introduction to Programming, using ECS & EBP in Rust

Crate of the Week

This week's crate is cargo-crap, a cargo subcommand to calculate the Change Risk Anti-Patterns metric for a crate.

Despite a lamentable lack of suggestions, llogiq is pleased with his choice.

Please submit your suggestions and votes for next week!

Calls for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.

If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs.

Let us know if you would like your feature to be tracked as a part of this list.

Call for Participation; projects and speakers

CFP - Projects

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon!

CFP - Events

Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.

• Scientific Computing in Rust 2026| 2026-06-05 | Virtual | 2026-07-08 - 2026-07-10

If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon!

Updates from the Rust Project

369 pull requests were merged in the last week

Compiler

• add Swift function call ABI
• implement pinned drop sugar

Library

• map_try_insert changes
• implement OsStr::split_at
• implement into_array for Vec<T>
• move std::io::Cursor to core::io
• move std::io::util to core::io
• widen the result of widening_mul

Cargo

• clean: respect build.target config for clean -p
• diag: Consolidate verify/run diagnostics passes
• diag: Report deferred diagnostics like other diagnostics
• diag: Pull in the parse pass
• lints: Avoid compiling where possible
• drop -Zunstable-options for rustdoc --emit

Rustdoc

• stabilize --emit flag
• correctly handle associated items in rustdoc macro expansion
• correctness & perf improvements to link-to-definition
• properly support macros with multiple kinds

Clippy

• fix duration_suboptimal_units for small literals
• fix arithmetic side effects false positive

Rust-Analyzer

• add diagnostic for E0029
• add diagnostic for E0614
• add diagnostic for E0638
• add handler for E0040
• encode the name instead of index in EnumVariantId
• fix assist qualify_path loses path segment
• add param on result methods for replace_method_eager_lazy
• complete ref_match in macro
• fully support pattern types
• handle usages in macro for extract_function
• no complete module colons before exists colons
• no lint unsized adt self_ty missing bounded assoc
• not complete same name inherent deref methods
• only ref match non-unknown value items
• show Run lens for fn main in bench targets
• handle TyKind::{Pat,UnsafeBinder} in has_drop_glue
• implement pattern_type macro
• method-resolution: emit error for method calls with illegal Sized bound
• migrate inline_call assist to SyntaxFactory
• perf: provide access to RootDatabase's LineIndex for the proc macro protocol
• show const in the signature help if applicable
• show unsafe in the signature help if applicable

Rust Compiler Performance Triage

Fewer than usual PRs merged, mostly due to a shorter week than normal and some CI trouble. Overall a slightly positive week for performance.

Triage done by @simulacrum. Revision range: 29b75901..281c97c3

0 Regressions, 0 Improvements, 4 Mixed; 1 of them in rollups 17 artifact comparisons made in total

Full report here

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

• Cargo RFC for min publish age

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

Tracking Issues & PRs

• Removing the unstable ptx linker flavor
• Create a new Tier 3 target: powerpc64le-unknown-none
• Optimize repr(Rust) enums by omitting tags in more cases involving uninhabited variants.
• Proposal for a dedicated test suite for the parallel frontend
• Promote tier 3 riscv32 ESP-IDF targets to tier 2
• Proposal for Adapt Stack Protector for Rust

No Items entered Final Comment Period this week for Rust, Rust RFCs, Cargo, Language Team, Language Reference, Leadership Council or Unsafe Code Guidelines.

Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.

New and Updated RFCs

• Documentation interpolation

Upcoming Events

Rusty Events between 2026-05-20 - 2026-06-17 🦀

Virtual

• 2026-05-20 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Mouse Control with Rust
• 2026-05-20 | Virtual (Girona, ES) | Rust Girona
  • Weekly coding session
• 2026-05-21 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • May, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-05-21 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-05-21 | Virtual (Charlottesville, VA, US) | Charlottesville Rust Meetup
  • Tock OS Part #4 - Capsule coding in QEMU!
• 2026-05-26 | Virtual (Cardiff, GB) | Rust and C++ Cardiff
  • Hybrid event with Rust Dortmund!
• 2026-05-26 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Fourth Tuesday
• 2026-05-26 | Virtual (London, UK) | Women in Rust
  • Lunch & Learn: Seeing Into Your Code - A Practical Guide to Tracing in Rust
• 2026-05-27 | Virtual (Girona, ES) | Rust Girona
  • Weekly coding session
• 2026-06-02 | Virtual | libp2p Events
  • rust-libp2p Open Maintainers Call
• 2026-06-03 | Virtual (Indianapolis, IN, US) | Indy Rust
  • Indy.rs - with Social Distancing
• 2026-06-04 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-06-04 | Virtual (Nürnberg, DE) | Rust Nuremberg
  • Rust Nürnberg online
• 2026-06-07 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: First Sunday
• 2026-06-09 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Second Tuesday
• 2026-06-10 | Virtual (Girona, ES) | Rust Girona
  • Weekly coding session
• 2026-06-16 | Virtual (Washington, DC, US) | Rust DC
  • Mid-month Rustful
• 2026-06-02 | Virtual | libp2p Events
  • rust-libp2p Open Maintainers Call
• 2026-06-17 | Virtual (Girona, ES) | Rust Girona
  • Weekly coding session
• 2026-06-17 | Virtual (Vancouver, BC, CA) | Vancouver Rust
  • Rust Study/Hack/Hang-out

Asia

• 2026-06-02 | Beijing, CN | Voice AI and Rust Meetup (Rust for AI, lowcoderust.com)
  • AI Agents and Open Source LLM (Call for Speakers)

Europe

• 2026-05-18 - 2026-05-23 | Utrecht, NL | RustWeek 2026
  • RustWeek 2026
• 2026-05-21 | Amsterdam, NL | RustNL
  • RustWeek Hackathon
• 2026-05-22 | Amsterdam, NL | RustNL
  • Walking Tour around Utrecht
• 2026-05-22 | Amsterdam, NL | RustNL
  • Bike tour around Utrecht
• 2026-05-26 | Dortmund, DE | Rust Dortmund
  • Rust Dortmund Meetup - Agentic Programming - May
• 2026-05-26 | Manchester, UK | Rust Manchester
  • Rust Manchester May Code Night
• 2026-05-26 | Trondheim, NO | Rust Trondheim
  • Motorized blinds, and replacing Docker, in Rust!
• 2026-05-28 | London, UK | Rust London User Group
  • LDN Talks May Community Showcase
• 2026-05-29 | Berlin, DE | Rust Berlin
  • Rust Berlin Talks: The next generation
• 2026-06-03 | Dublin, IE | Rust Dublin
  • Join us live and INPERSON for Rust 261
• 2026-06-03 | Girona, ES | Rust Girona
  • Rust Girona Hack & Learn 06 2026
• 2026-06-11 | Switzerland, CH | PostTenebrasLab
  • Rust Meetup Geneva
• 2026-06-16 | Leipzig, SN, DE | Rust - Modern Systems Programming in Leipzig
  • Interactive: Everything is Open Source

North America

• 2026-05-20 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Mouse Control with Rust
• 2026-05-20 | San Francisco, CA, US | Bay Area Rust Meetup
  • Bay Area Rust Meetup
• 2026-05-21 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • May, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-05-21 | New York, NY, US | Rust NYC
  • Rust NYC: "Boring File Storage" & "Indie News Feed Optimization"
• 2026-05-21 | Nashville, TN, US | Music City Rust Developers
  • Community Meetup
• 2026-05-23 | Boston, MA, US | Boston Rust Meetup
  • Allston Rust Lunch, May 23
• 2026-05-27 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground
• 2026-05-28 | Atlanta, GA, US | Rust Atlanta
  • Rust-Atl
• 2026-05-28 | Los Angeles, CA, US | Rust Los Angeles
  • Rust LA: Rust in Embedded & Autonomous Systems at Parallel Systems in DTLA
• 2026-05-28 | Mountain View, CA, US | Hacker Dojo
  • RUST MEETUP at HACKER DOJO
• 2026-05-30 | Boston, MA, US | Boston Rust Meetup
  • Central Cambridge Rust Lunch, May 30
• 2026-06-04 | Saint Louis, MO, US | STL Rust
  • Testing, Coverage, Tracey & Mutations
• 2026-06-06 | Boston, MA, US | Boston Rust Meetup
  • Boston Common Rust Lunch, June 6
• 2026-06-11 | Lehi, UT, US | Utah Rust
  • Utah Rust June Meetup
• 2026-06-11 | San Diego, CA, US | San Diego Rust
  • San Diego Rust June Meetup - Back in person!
• 2026-06-16 | San Francisco, CA, US | San Francisco Rust Study Group
  • Rust Hacking in Person