HTTP/2 200 server: GitHub.com content-type: application/xml last-modified: Tue, 07 Oct 2025 17:47:30 GMT access-control-allow-origin: * etag: W/"68e55232-2cbed" expires: Tue, 07 Oct 2025 18:04:08 GMT cache-control: max-age=600 content-encoding: gzip x-proxy-cache: MISS x-github-request-id: 745A:3FABB1:9A4F:B4FF:68E553BF accept-ranges: bytes age: 359 date: Fri, 10 Oct 2025 18:00:04 GMT via: 1.1 varnish x-served-by: cache-bom-vanm7210077-BOM x-cache: HIT x-cache-hits: 0 x-timer: S1760119204.407160,VS0,VE1 vary: Accept-Encoding x-fastly-request-id: 50c4451c230a2ae96a223c10b0f303e6ee4303e9 content-length: 40177 Inside Rust Blog https://blog.rust-lang.org/inside-rust/ Want to follow along with Rust development? Curious how you might get involved? Take a look! Maintained by the Rust Teams. https://github.com/rust-lang/blog.rust-lang.org/ 2025-10-07T17:47:15+00:00 2025-10-01T00:00:00+00:00 2025-10-01T00:00:00+00:00 https://blog.rust-lang.org/inside-rust/2025/10/01/this-development-cycle-in-cargo-1.90/ <h1 id="this-development-cycle-in-cargo-1-90"><a class="anchor" href="#this-development-cycle-in-cargo-1-90" aria-hidden="true"></a> This Development-cycle in Cargo: 1.90</h1> <p>This is a summary of what has been happening around Cargo development for the last 6 weeks which is approximately the merge window for Rust 1.90 as well as highlights from 1.87, 1.88, 1.89.</p> <!-- time period: 2025-02-20 through 2025-09-18 --> <ul> <li><a href="https://blog.rust-lang.org/inside-rust/2025/10/01/this-development-cycle-in-cargo-1.90/#plugin-of-the-cycle">Plugin of the cycle</a></li> <li><a href="https://blog.rust-lang.org/inside-rust/2025/10/01/this-development-cycle-in-cargo-1.90/#implementation">Implementation</a> <ul> <li><a href="https://blog.rust-lang.org/inside-rust/2025/10/01/this-development-cycle-in-cargo-1.90/#gsoc-alternative-design-for-cargo-fix">GSoC: Alternative design for <code>cargo fix</code></a></li> <li><a href="https://blog.rust-lang.org/inside-rust/2025/10/01/this-development-cycle-in-cargo-1.90/#gsoc-prototype-a-new-set-of-cargo-plumbing-commands">GSoC: Prototype a new set of Cargo "plumbing" commands</a></li> <li><a href="https://blog.rust-lang.org/inside-rust/2025/10/01/this-development-cycle-in-cargo-1.90/#gsoc-build-script-delegation">GSoC: Build script delegation</a></li> <li><a href="https://blog.rust-lang.org/inside-rust/2025/10/01/this-development-cycle-in-cargo-1.90/#target-host"><code>--target host</code></a></li> <li><a href="https://blog.rust-lang.org/inside-rust/2025/10/01/this-development-cycle-in-cargo-1.90/#annotate-snippets">annotate-snippets</a></li> </ul> </li> <li><a href="https://blog.rust-lang.org/inside-rust/2025/10/01/this-development-cycle-in-cargo-1.90/#design-discussions">Design discussions</a> <ul> <li><a href="https://blog.rust-lang.org/inside-rust/2025/10/01/this-development-cycle-in-cargo-1.90/#all-hands-xdg-paths">All hands: XDG paths</a></li> <li><a href="https://blog.rust-lang.org/inside-rust/2025/10/01/this-development-cycle-in-cargo-1.90/#all-hands-cargo-linting">All hands: cargo linting</a></li> <li><a href="https://blog.rust-lang.org/inside-rust/2025/10/01/this-development-cycle-in-cargo-1.90/#all-hands-doctests">All hands: doctests</a></li> <li><a href="https://blog.rust-lang.org/inside-rust/2025/10/01/this-development-cycle-in-cargo-1.90/#all-hands-code-gen-settings">All hands: code-gen settings</a></li> <li><a href="https://blog.rust-lang.org/inside-rust/2025/10/01/this-development-cycle-in-cargo-1.90/#all-hands-cargo-explain">All hands: <code>cargo explain</code></a></li> <li><a href="https://blog.rust-lang.org/inside-rust/2025/10/01/this-development-cycle-in-cargo-1.90/#cargo-doc-serve"><code>cargo doc --serve</code></a></li> <li><a href="https://blog.rust-lang.org/inside-rust/2025/10/01/this-development-cycle-in-cargo-1.90/#multi-line-messages-from-build-scripts">Multi-line messages from build scripts</a></li> <li><a href="https://blog.rust-lang.org/inside-rust/2025/10/01/this-development-cycle-in-cargo-1.90/#forgetting-cargo-fmt-after-cargo-fix">Forgetting <code>cargo fmt</code> after <code>cargo fix</code></a></li> <li><a href="https://blog.rust-lang.org/inside-rust/2025/10/01/this-development-cycle-in-cargo-1.90/#recursively-find-dependencies-at-a-path">Recursively find dependencies at a <code>path</code></a></li> <li><a href="https://blog.rust-lang.org/inside-rust/2025/10/01/this-development-cycle-in-cargo-1.90/#include-workspace-license-files-with-cargo-new">Include workspace license files with <code>cargo new</code></a></li> </ul> </li> <li><a href="https://blog.rust-lang.org/inside-rust/2025/10/01/this-development-cycle-in-cargo-1.90/#misc">Misc</a></li> <li><a href="https://blog.rust-lang.org/inside-rust/2025/10/01/this-development-cycle-in-cargo-1.90/#focus-areas-without-progress">Focus areas without progress</a></li> </ul> <h2 id="plugin-of-the-cycle"><a class="anchor" href="#plugin-of-the-cycle" aria-hidden="true"></a> Plugin of the cycle</h2> <p>Cargo can't be everything to everyone, if for no other reason than the compatibility guarantees it must uphold. Plugins play an important part of the Cargo ecosystem and we want to celebrate them.</p> <p>Our plugin for this cycle is <a href="https://crates.io/crates/cargo-deny"><code>cargo-deny</code></a>, a linter for Cargo. A builtin linter for Cargo is being tracked in <a href="https://github.com/rust-lang/cargo/issues/12235">#12235</a> along with <a href="https://github.com/rust-lang/cargo/issues?q=is%3Aissue%20state%3Aopen%20label%3AA-new-lint">ideas for lints</a>.</p> <p>Thanks to <a href="https://github.com/kpreid">krpeid</a> for the suggestion!</p> <p><a href="https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Plugin.20of.20the.20Dev.20Cycle/near/420703211">Please submit your suggestions for the next post.</a></p> <h2 id="implementation"><a class="anchor" href="#implementation" aria-hidden="true"></a> Implementation</h2> <h3 id="gsoc-alternative-design-for-cargo-fix"><a class="anchor" href="#gsoc-alternative-design-for-cargo-fix" aria-hidden="true"></a> GSoC: Alternative design for <code>cargo fix</code></h3> <p><code>cargo fix</code> will apply suggested fixes for lints and has worked well for cleaning up sloppy code, reducing the annoyance of toolchain upgrades where lints may change, helping with Edition migrations, and adopting of new lints in a code base.</p> <p>However, <code>cargo fix</code></p> <ul> <li>Can be slow (<a href="https://github.com/rust-lang/cargo/issues/13214">#13214</a>)</li> <li>Only applies a subset of possible lints</li> <li>Can't be selective of which lints are fixed without a lot of mucking with <code>RUSTFLAGS</code> which was important with the 2024 Edition migration because some lints still had a lot of false positives at first</li> </ul> <p>A problem with addressing these is the current architecture. <code>cargo fix</code> is implemented as a variant of <code>cargo check</code> that replaces <code>rustc</code> with <code>cargo</code> being run in a special mode that will call <code>rustc</code> in a loop, applying fixes until there are none. While this special <code>rustc</code>-proxy mode is running, a cross-process lock is held to force only one build target to be fixed at a time to avoid race conditions. This ensures correctness at the cost of performance and difficulty in making the <code>rustc</code>-proxy interactive.</p> <p><a href="https://github.com/crate-ci/cargo-fixit">cargo-fixit</a> is a Proof of Concept for an alternative design, developed by <a href="https://github.com/Pyr0de">Pyr0de</a>. With this design, <code>cargo fixit</code> spawns <code>cargo check</code> in a loop, determining which build targets are safe to fix in this pass, and applying the suggestions. This puts the top-level program in charge of what fixes get applied, making it easier to coordinate, allowing the locking to be removed and opening the door to an interactive mode. This comes at the cost that fixes in packages lower in the dependency tree can cause later packages to rebuild multiple times, slowing things down.</p> <p>Regarding performance, cargo-fixit is <a href="https://github.com/crate-ci/cargo-fixit/blob/main/benchsuite/runs/2025-07-31-af6627c.md">showing promising results</a>.</p> <p>There remains</p> <ul> <li>Investigations into whether other optimizations are safe (<a href="https://github.com/crate-ci/cargo-fixit/issues/52">cargo-fixit#52</a>, <a href="https://github.com/crate-ci/cargo-fixit/issues/21">cargo-fixit#21</a>)</li> <li>Open questions on how the <code>cargo fix</code> interface should be maintained with this new design (<a href="https://github.com/crate-ci/cargo-fixit/milestone/5">stabilization issues</a>)</li> <li>Finish handling all of the remaining functionality</li> </ul> <h3 id="gsoc-prototype-a-new-set-of-cargo-plumbing-commands"><a class="anchor" href="#gsoc-prototype-a-new-set-of-cargo-plumbing-commands" aria-hidden="true"></a> GSoC: Prototype a new set of Cargo "plumbing" commands</h3> <p>We've had a <a href="https://rust-lang.github.io/rust-project-goals/2025h2/cargo-plumbing.html">project goal for plumbing commands</a> for a while and <a href="https://github.com/secona">secona</a> wrote <a href="https://github.com/crate-ci/cargo-plumbing">cargo-plumbing</a> as a prototype. The focus was on better understanding of what the plumbing commands can look like and what is needed from Cargo. Compromises had to be made in the actual result to not be blocked on what the Cargo Rust APIs currently allow (<a href="https://github.com/crate-ci/cargo-plumbing/issues/82">cargo-plumbing#82</a>). For example, instead of solely relying on the manifests that the user passed in, the plumbing commands will re-read the manifests within each command, preventing callers from being able to edit them to get specific behavior out of Cargo, e.g. dropping all workspace members to allow resolving dependencies on a per-package basis.</p> <p><code>cargo-plumbing</code> currently covers</p> <ul> <li><code>locate-manifest</code></li> <li><code>read-manifest</code></li> <li><code>read-lockfile</code></li> <li><code>lock-dependencies</code></li> <li><code>write-lockfile</code></li> <li><code>resolve-features</code></li> <li><code>plan-build</code></li> </ul> <h3 id="gsoc-build-script-delegation"><a class="anchor" href="#gsoc-build-script-delegation" aria-hidden="true"></a> GSoC: Build script delegation</h3> <p>Build scripts come at a compile time cost. Even with <code>cargo check</code>, they must be built as if you ran <code>cargo build</code> so they can be run. While we need to identify ways to abstract common build script patterns (<a href="https://github.com/rust-lang/cargo/issues/14948">#14948</a>), that may not always be doable. However, if we can shift build scripts from being defined in every package that needs the functionality into a couple of core build script packages, we can reduce the number of build scripts that need to be built and linked.</p> <p>The first step in being able to delegate build scripts to packages is to be able to have multiple build scripts which is what <a href="https://github.com/namanlp">namanlp</a> has developed so far.</p> <p>You can have</p> <pre data-lang="toml" class="language-toml z-code"><code class="language-toml" data-lang="toml"><span class="z-source z-toml"><span class="z-punctuation z-definition z-table z-begin z-toml">[</span><span class="z-meta z-tag z-table z-toml"><span class="z-entity z-name z-table z-toml">package</span></span><span class="z-punctuation z-definition z-table z-end z-toml">]</span> </span><span class="z-source z-toml"><span class="z-meta z-tag z-key z-toml"><span class="z-entity z-name z-tag z-toml">build</span></span> <span class="z-punctuation z-definition z-key-value z-toml">=</span> <span class="z-punctuation z-definition z-array z-begin z-toml">[</span><span class="z-string z-quoted z-double z-basic z-toml"><span class="z-punctuation z-definition z-string z-begin z-toml">&quot;</span>windows-manifest.rs<span class="z-punctuation z-definition z-string z-end z-toml">&quot;</span></span><span class="z-punctuation z-separator z-array z-toml">,</span> <span class="z-string z-quoted z-double z-basic z-toml"><span class="z-punctuation z-definition z-string z-begin z-toml">&quot;</span>release-info.rs<span class="z-punctuation z-definition z-string z-end z-toml">&quot;</span></span><span class="z-punctuation z-definition z-array z-end z-toml">]</span> </span></code></pre> <p>and your package can access their <code>OUT_DIR</code>s as <code>env!("windows-manifest_OUT_DIR")</code> and <code>env!("release-info_OUTDIR")</code> (<a href="https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#metabuild">documentation</a>).</p> <p>The next phase is static parameters being defined in <code>Cargo.toml</code> and then specifying dependencies using <a href="https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#artifact-dependencies">artifact-dependencies</a>.</p> <h3 id="target-host"><a class="anchor" href="#target-host" aria-hidden="true"></a> <code>--target host</code></h3> <p>The following two commands are not equivalent:</p> <pre data-lang="console" class="language-console z-code"><code class="language-console" data-lang="console"><span class="z-text z-plain">$ cargo build </span><span class="z-text z-plain">$ cargo build --target `rustc --print host-tuple` </span></code></pre> <p>While they both build for the host's platform tuple, the first is run in "host mode" while the second is run in "cross-compilation mode". In "host mode", build scripts and proc-macros are built the same as binaries and tests, including <code>RUSTFLAGS</code> being applied, and everything is output to <code>target/&lt;profile&gt;</code>. In "cross-compilation mode" with the host's tuple, everything still builds for the host's tuple but <code>RUSTFLAGS</code> are not passed to build scripts and proc-macros and everything is output to <code>target/&lt;tuple&gt;/&lt;profile&gt;</code>.</p> <p>Some challenges with this:</p> <ul> <li>Naively, someone may run <code>cargo build</code> for packaging artifacts for their current platform and <code>cargo --target &lt;tuple&gt;</code> for packaging artifacts for other platforms and the difference in the artifact-dir causes confusion and frustration in automation.</li> <li>In some cross-compilation scenarios, users also need to specify <code>RUSTFLAGS</code> for their build scripts and proc-macros.</li> <li>When setting <a href="https://doc.rust-lang.org/cargo/reference/config.html#buildtarget"><code>build.target</code></a> to a specific platform tuple, there wouldn't be a way to set it back to the host without hard coding a specific host, whether host mode or cross-compilation mode</li> </ul> <p><a href="https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#target-applies-to-host"><code>target-applies-to-host</code></a> and <a href="https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#host-config"><code>host-config</code></a> are unstable features that have tried to address this.</p> <p>In <a href="https://github.com/rust-lang/cargo/issues/13051">#13051</a>, <a href="https://github.com/kpreid">kpreid</a> suggested a related feature to <code>target-applies-to-host</code>, a platform-tuple placeholder where the following mean the same thing:</p> <pre data-lang="console" class="language-console z-code"><code class="language-console" data-lang="console"><span class="z-text z-plain">$ cargo build --target host </span><span class="z-text z-plain">$ cargo build --target `rustc --print host-tuple` </span></code></pre> <p>A user could then opt-in to always being in "cross-compilation" mode by setting in <code>~/.cargo/config.toml</code>:</p> <pre data-lang="toml" class="language-toml z-code"><code class="language-toml" data-lang="toml"><span class="z-source z-toml"><span class="z-punctuation z-definition z-table z-begin z-toml">[</span><span class="z-meta z-tag z-table z-toml"><span class="z-entity z-name z-table z-toml">build</span></span><span class="z-punctuation z-definition z-table z-end z-toml">]</span> </span><span class="z-source z-toml"><span class="z-meta z-tag z-key z-toml"><span class="z-entity z-name z-tag z-toml">target</span></span> <span class="z-punctuation z-definition z-key-value z-toml">=</span> <span class="z-string z-quoted z-double z-basic z-toml"><span class="z-punctuation z-definition z-string z-begin z-toml">&quot;</span>host<span class="z-punctuation z-definition z-string z-end z-toml">&quot;</span></span> </span></code></pre> <!-- 2025-08-11 --> <p>When talking about this as a team, one concern was where all this could apply. For example, the following might not make sense:</p> <pre data-lang="toml" class="language-toml z-code"><code class="language-toml" data-lang="toml"><span class="z-source z-toml"><span class="z-punctuation z-definition z-table z-begin z-toml">[</span><span class="z-meta z-tag z-table z-toml"><span class="z-entity z-name z-table z-toml">target</span><span class="z-punctuation z-separator z-table z-toml">.</span><span class="z-entity z-name z-table z-toml">host</span><span class="z-punctuation z-separator z-table z-toml">.</span><span class="z-entity z-name z-table z-toml">dependencies</span></span><span class="z-punctuation z-definition z-table z-end z-toml">]</span> </span><span class="z-source z-toml"><span class="z-meta z-tag z-key z-toml"><span class="z-entity z-name z-tag z-toml">regex</span></span> <span class="z-punctuation z-definition z-key-value z-toml">=</span> <span class="z-string z-quoted z-double z-basic z-toml"><span class="z-punctuation z-definition z-string z-begin z-toml">&quot;</span>1<span class="z-punctuation z-definition z-string z-end z-toml">&quot;</span></span> </span></code></pre> <p>We decided the alias would only exist for <code>--target</code> / <code>build.target</code> for now. We can evaluate where it makes sense to expand from there.</p> <p>Another issue was whether <code>host</code> would work as a placeholder. As we'd be carving out <code>host</code> from possible values, we'd need to know whether that is safe. We checked with T-compiler at <a href="https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/.60--target.3Dhost.60.20as.20alias.20to.20host.20triple.20in.20cargo/near/534227313">#t-compiler &gt; `--target=host` as alias to host triple in cargo @ 💬</a> and they were fine with it. There is the question of whether <code>host</code> is clear that this is a placeholder for the host tuple or if it could be confused with "host mode" and the unstable <code>[host]</code> table for host builds. One idea was to name it <code>{host}</code>, to make this an explicit variable substitution but weren't thrilled with that, especially on the command-line. For now, we've settled on <code>host-tuple</code> though the stabilization discussion is still on-going.</p> <h3 id="annotate-snippets"><a class="anchor" href="#annotate-snippets" aria-hidden="true"></a> annotate-snippets</h3> <p><em>Update from <a href="https://blog.rust-lang.org/inside-rust/2024/03/26/this-development-cycle-in-cargo-1.78/#user-controlled-cargo-diagnostics">1.78</a></em></p> <p><a href="https://github.com/Muscraft/">Muscraft</a> released annotate-snippets <a href="https://github.com/rust-lang/annotate-snippets-rs/blob/master/CHANGELOG.md#0120---2025-08-28">0.12</a> which includes</p> <ul> <li>swapping in rustc's renderer and fixing many bugs</li> <li>API re-design</li> </ul> <p>This release is in preparation for replacing rustc's renderer with annotate-snippets. At this point, it appears that annotate-snippets is flexible enough and complete enough to handle all of rustc's needs and the remaining issues are with rustc itself and the adapter between rustc and annotate-snippets.</p> <p>With annotate-snippets v0.12 out, <a href="https://github.com/epage">epage</a> started the effort to switch Cargo's user messages over to it which is being tracked in <a href="https://github.com/rust-lang/cargo/issues/15944">#15944</a>.</p> <h2 id="design-discussions"><a class="anchor" href="#design-discussions" aria-hidden="true"></a> Design discussions</h2> <h3 id="all-hands-xdg-paths"><a class="anchor" href="#all-hands-xdg-paths" aria-hidden="true"></a> All hands: XDG paths</h3> <!-- https://hackmd.io/oA1Ek1fBQxiMkql6osYq6A --> <p>Cargo stores all of its user-wide content under <code>CARGO_HOME</code>, usually <code>~/.cargo</code>, including configuration, caches, and locally built binaries. There has been a long standing request to use the OS native paths for these, particularly <a href="https://specifications.freedesktop.org/basedir-spec/latest/">XDG Base Directories</a> (<a href="https://github.com/rust-lang/cargo/issues/1734">#1734</a>).</p> <p>While it can be difficult to take an existing application and migrate data to a new location without breaking compatibility, what makes this more difficult includes:</p> <ul> <li>Different versions of Cargo are expected to run side-by-side</li> <li><a href="https://rustup.rs/"><code>rustup</code></a> integrates with <code>CARGO_HOME</code> and is versioned independent of Cargo and supports interacting with every version of Cargo <ul> <li>They both use <code>$CARGO_HOME/bin</code> for installing binaries</li> <li>Rustup sets up <code>$CARGO_HOME/env</code> for users to source for adding <code>$CARGO_HOME/bin</code> to their <code>PATH</code> to access both Rustup and Cargo installed binaries</li> <li>Rustup cleans up rustup and cargo content, including <code>$CARGO_HOME/bin</code> on uninstall</li> <li>Cargo needs to be able to find third-party subcommands installed by both Cargo and Rustup</li> <li>Rustup's <code>cargo</code> proxy always sets <code>CARGO_HOME</code> on the real <code>cargo</code></li> </ul> </li> </ul> <p>Working through the Cargo / Rustup interactions has been a problem for moving this forward (including the existing <a href="https://internals.rust-lang.org/t/pre-rfc-split-cargo-home/19747">Phase 1 Pre-RFC</a>) and we were able to get the Cargo and Rustup teams together at the All Hands to talk through these problems.</p> <p>The most immediate problem is Rustup setting <code>CARGO_HOME</code>. To not break compatibility, Cargo should always respect it if <code>CARGO_HOME</code> is set. However, if Rustup always sets it, then Cargo will never use OS native paths. The intention behind Rustup setting <code>CARGO_HOME</code> is to make sure Rustup and Cargo use the same <code>CARGO_HOME</code> for <code>bin/</code> and <code>env</code>. This was particularly a problem at some point in the past when they did not agree on a definition. Because new versions of Rustup work with old versions of Cargo, this remains an issue.</p> <p>Both teams suspect it will be acceptable at this point for Rustup to stop setting <code>CARGO_HOME</code>. However, we first need to characterize their diverging definitions of <code>CARGO_HOME</code> and see if there is anything we can do to mitigate user problems. This is being tracked in <a href="https://github.com/rust-lang/rustup/issues/4502">rustup#4502</a>.</p> <p>As Cargo then moves to OS native paths, does Rustup need to continue to match behavior and use the same paths? This boiled down to whether Rustup should continue to cleanup <code>CARGO_HOME/bin</code>, caches, and config on uninstall. If a user sets <code>~/.local/bin</code> as their install path, Rustup could end up deleting user binaries. In fact, Rustup does it today because some applications have chosen to install their binaries into <code>~/.cargo/bin</code>, even if they weren't installed by <code>cargo install</code>. It's also likely not a good idea to be deleting the users configuration. We decided that Rustup should only remove content it manages (<a href="https://github.com/rust-lang/rustup/issues/285">rustup#285</a>).</p> <p>With that resolved, we can consider on its own merits whether to use the same paths. We leaned towards them being configured separately but first we need to test the user experience for this to see how well it will work in practice. We should at least coordinate on whether to use application or XDG paths on Mac.</p> <p>As for <code>$CARGO_HOME/.env</code>, our expectation is that it will contain the default bin path for both Rustup and Cargo.</p> <p>The rest of the mechanics are more program specific. We talked a bit about Cargo's transition. We still plan to do this in two phases, (1) make the more granular paths configurable and then (2) change the defaults to OS native paths. The change to OS native paths might not even need to happen in one go so long as we've solve the policy questions (particularly for Mac). For config, Cargo can read from both locations. For caches, Cargo can abandon the old location though there is a question of how to handle the cache garbage collection database, whether to have them be distinct or not. There is a question on how to transition the bin path.</p> <h3 id="all-hands-cargo-linting"><a class="anchor" href="#all-hands-cargo-linting" aria-hidden="true"></a> All hands: cargo linting</h3> <p><em>Update from <a href="https://blog.rust-lang.org/inside-rust/2024/10/31/this-development-cycle-in-cargo-1.83/#linting">1.83</a></em></p> <!-- 2025-04-22 --> <p>In preparing for the All Hands, <a href="https://github.com/epage">epage</a> ran a vibe check for <a href="https://blog.rust-lang.org/inside-rust/2024/10/31/this-development-cycle-in-cargo-1.83/#linting">previously raised questions</a>, including:</p> <ul> <li>What is the intent for the Rustc/Clippy divide and should Cargo mirror it?</li> <li>What namespace should Cargo lints live in?</li> <li>If Cargo share a namespace with Rustc or Clippy, should <code>RUSTFLAGS</code> affect cargo? <ul> <li>e.g. given <code>RUSTFLAGS=-Ddeprecated cargo check</code>, should Cargo <code>deprecated</code> warnings also error?</li> </ul> </li> </ul> <p>We mostly focused the discussion on <code>RUSTFLAGS</code> behavior. This would likely be implemented by Cargo passing the <code>RUSTFLAGS</code> to Rustc and asking it to print the effective lint level for the lints. This felt convoluted to the team and <code>RUSTFLAGS</code> is intended as a low-level escape hatch and we should not be elevating its use in this way.</p> <!-- https://hackmd.io/bRs_A-SgSoWKGqc4YCSJIA --> <p>At the All Hands, the above questions were re-visited with members of the Cargo team, Compiler team, and Clippy team. While there is a quality divide between Rustc and Clippy, including performance, the general sentiment is to avoid the divide unless you absolutely have to.</p> <p>One difference between Rustc and Clippy lints that was called out is that Clippy is more strict. When a Clippy lint is uplifted into Rustc, the severity is lowered. A lint that is a <code>deny</code> for Clippy would be a <code>warn</code> for Rustc.</p> <p>The Clippy team also recommended adopting organizing lints by semantic groups that have the same lint level for the entire group, like <a href="https://doc.rust-lang.org/clippy/">Clippy's groups</a>. This still leaves figuring out how this intersects with the lint levels having different meanings between Rustc and Clippy. If Cargo calibrates to Rustc's lint levels, should Cargo lower the severity of the groups or be more selective about what goes into each group?</p> <p>When discussing the namespace for Cargo lints, the recommendation is that Cargo only use the <code>cargo::</code> namespace, keeping the focus on the linter, at the cost of requiring users to common lints in two different places, even if it has extra configuration like <a href="https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html"><code>unexpected_cfgs</code></a>. Another reason for Cargo to focus on the <code>cargo::</code> namespace is to make it easier for users to identify correctly where to open issues.</p> <p>With these discussions out of the way, we can continue to work towards stabilizing Cargo's linter (<a href="https://github.com/rust-lang/cargo/issues/12235">#12235</a>).</p> <p>In preparation for that, we improved our tracking of new lints, including:</p> <ul> <li>Adopted a clippy-like template for requesting lints</li> <li>Created Issues for <a href="https://rust-lang.github.io/rust-clippy/stable/index.html?groups=cargo">existing</a> and <a href="https://github.com/rust-lang/rust-clippy/issues?q=is%3Aissue%20state%3Aopen%20label%3AT-cargo">requested</a> Clippy Cargo lints</li> <li>Add an <a href="https://github.com/rust-lang/cargo/issues?q=is%3Aissue%20state%3Aopen%20label%3AA-new-lint"><code>A-new-lint</code></a> tag</li> </ul> <h3 id="all-hands-doctests"><a class="anchor" href="#all-hands-doctests" aria-hidden="true"></a> All hands: doctests</h3> <p><em>Update from <a href="https://blog.rust-lang.org/inside-rust/2024/10/01/this-development-cycle-in-cargo-1.82/#all-targets-and-doc-tests">1.82</a></em></p> <p>When Cargo runs doctests, it invokes <code>rustdoc</code> against the library to build and run the tests. This runs counter to the way the rest of Cargo works which creates warts in behavior, requiring special cases to workaround, and frustrating users (e.g. a recent <a href="https://www.reddit.com/r/rust/comments/1noj73x/are_doctests_painful_to_write_or_is_it_just_me/">reddit thread</a>).</p> <p>Some examples of problems with doctests are:</p> <ul> <li>inability to run <code>cargo check</code> or <code>cargo clippy</code> on them</li> <li><code>cargo test --workspace</code> rebuilding doctests when there was no change</li> <li>cargo can't collect "unused dependency" messages from rustc to identify which dependencies are unused across all dev-dependencies</li> </ul> <p>This also affects future plans including:</p> <ul> <li>Coverage reporting (<a href="https://github.com/rust-lang/cargo/issues/13040">#13040</a>)</li> <li>Cargo providing improved output (e.g. <a href="https://github.com/rust-lang/cargo/issues/2832">#2832</a>)</li> </ul> <p>The Testing DevEx team has done some brainstorming on this problem (<a href="https://github.com/rust-lang/testing-devex-team/issues/5">testing-devex-team#5</a>), including:</p> <ul> <li>Building doctest support into the compiler, parsing <code>#[doc]</code> attributes and generating <code>#[test]</code> functions for them <ul> <li>Allows doctests on internal items and binary targets</li> <li>Doesn't allow for the "public interface" testing unless Rustc also links to the original lib or do some import path hackery</li> <li>Has issues with features like <code>compile_fail</code> and per-doctest Editions</li> </ul> </li> <li>Using <code>rustdoc --output-format=doctest</code> to extract doctests, generate test files, build, and then run those (<a href="https://github.com/rust-lang/rust/issues/134529">rust#134529</a>)</li> </ul> <!-- https://hackmd.io/68nIlljST5y-h0xZa9Gt4g --> <!-- https://hackmd.io/kQttcFQpQJa7WrQ3J5uLAg --> <!-- https://hackmd.io/@fmease/inject-doctests-into-host-crate --> <!-- 2025-05-20 --> <p><a href="https://github.com/epage">epage</a> took this to the Rustdoc team at the All Hands. They had a variant of rustc having built-in knowledge of doctests: run <code>rustdoc</code> as an alternative compiler driver that will do the translation. This idea was recorded in <a href="https://github.com/rust-lang/rust/issues/141083">rust#141083</a>. One problem that came up later on the issue is <code>cargo clippy</code> support as that is a separate compiler driver. One idea is for the logic to be in rustc itself any drivers that link against it can provide a <code>--doctest</code> flag like the <code>--test</code> flag.</p> <p>This is still left as an open area to further explore.</p> <h3 id="all-hands-code-gen-settings"><a class="anchor" href="#all-hands-code-gen-settings" aria-hidden="true"></a> All hands: code-gen settings</h3> <!-- 2025-04-01 --> <p>The Cargo team discussed a request for exposing <code>-Cforce-frame-pointers</code> in <a href="https://doc.rust-lang.org/cargo/reference/profiles.html#custom-profiles"><code>[profiles]</code></a> (<a href="https://github.com/rust-lang/cargo/issues/15333">#15333</a>). This seemed like a reasonable idea. We decided against changing the <code>bench</code> profile to have this enabled so that <code>cargo bench</code> and <code>cargo build --release</code> do the same thing by default.</p> <p>This does tie into the broader question about deciding what compiler settings should be set in <code>[profiles]</code> and if we can smooth out the process. The burden for adding new settings across both rustc and cargo was highlighted by <a href="https://github.com/kornelski">kornelski</a> on <a href="https://internals.rust-lang.org/t/the-burden-of-creating-new-compiler-options-and-exposing-them-in-cargo/22101">Internals</a> this is made harder by the fact that the Cargo team is generally disconnected from the development of these requests and it can be difficult to have the context for how these should be exposed in a higher-level, opinionated tool like Cargo.</p> <!-- https://hackmd.io/KbOUdlszRgCpMyWb1-YjVA --> <p>The Cargo team followed up with the Compiler team at the All Hands. An idea was discussed of a <code>profile.*.codegen</code> field that would accept a list of <a href="https://doc.rust-lang.org/nightly/rustc/codegen-options/index.html"><code>-C</code> code-gen settings</a> in a format Cargo could check against an allowlist, normalize, and de-duplicate. Some <code>-Z</code> flags, like <code>Z fmt-debug</code>, may need to be turned into <code>-Zunstable-options -C fmg-debug</code> to work with this.</p> <p>The allowlist is important because Cargo's abstractions over rustc are intended to not be able to create unsound programs (e.g. having different floating point settings between compilation units) and to prevent arbitrary injection through response files. Updating the allowlist could be a step in the stabilization report and provide a sync point between the Compiler and Cargo team meetings which is currently lacking.</p> <!-- 2025-05-20 --> <p>We then followed up on this in a Cargo team meeting as not everyone was at the All Hands or even at that session.</p> <p>Unlike <code>RUSTFLAGS</code>, this is something Cargo can reasonably parse and validate. However, both have the problem of potentially interacting poorly with built-in Cargo behavior. The allowlist could help with this as well.</p> <p>We did not come to any definitive answer in the discussion.</p> <h3 id="all-hands-cargo-explain"><a class="anchor" href="#all-hands-cargo-explain" aria-hidden="true"></a> All hands: <code>cargo explain</code></h3> <!-- https://hackmd.io/KbOUdlszRgCpMyWb1-YjVA --> <p>At the All Hands, <a href="https://github.com/timclicks">timclicks</a> attended an open time with the Cargo team to discuss ways to improve the experience with compiler diagnostics. The core of the idea is to provide one place for users to go to get more detailed information on an error code or lint name. Currently, you can view error code descriptions with <code>rustc --explain</code> or <code>cargo --explain</code> and clippy lints with <code>cargo clippy --explain</code>. There isn't a local view for rustc lints. These views dump markdown to the screen without any styling.</p> <p><a href="https://github.com/timclicks">timclicks</a> proposed there to be a <code>cargo explain</code> subcommand that could take in an error code or lint name and stylize the markdown output. There is the question of how information for third-party lints could be found once <a href="https://github.com/rust-lang/rust/issues/66079">rust#66079</a> is stabilized.</p> <p>This could be well served by having a built-in pager (<a href="https://github.com/rust-lang/cargo/issues/11213">#11213</a>). This led <a href="https://github.com/epage">epage</a> to floating an idea that he has been considering for a bit: supporting a compilation watch mode (<a href="https://github.com/rust-lang/cargo/issues/9339">#9339</a>) but in the style of <a href="https://dystroy.org/bacon/">bacon</a>. Combined with this idea of <code>cargo explain</code>, maybe it could be an interactive mode (e.g. <code>cargo check -i</code>) that allowed you to select a diagnostic and have it pop up an "explain" view. In response, someone brought up that the compiler knows more than is currently shown and maybe this could be included in the json output so that the user could drill further into a diagnostic in interactive mode. Like with many other subcommands, this would likely best be experimented with as a <a href="https://doc.rust-lang.org/cargo/reference/external-tools.html#custom-subcommands">custom subcommand</a> before integrating it into Cargo.</p> <h3 id="cargo-doc-serve"><a class="anchor" href="#cargo-doc-serve" aria-hidden="true"></a> <code>cargo doc --serve</code></h3> <!-- 2025-06-03 --> <p>The Cargo team reviewed an old requested for <code>cargo doc</code> to get a <code>--serve</code> flag (<a href="https://github.com/rust-lang/cargo/issues/4966">#4966</a>). The given use case is for web browsers that limit plugin access to <code>file://</code> URLs. This also seems relevant for <a href="https://learn.microsoft.com/en-us/windows/wsl/">WSL</a>, dev containers, and remote development. However, we would be concerned about anyone using this in production.</p> <p>If the <code>cargo doc</code> process is staying alive to serve files, it seems a natural extension to rebuild the documentation on changes (<a href="https://github.com/rust-lang/cargo/issues/9339">#9339</a>). That can then lead to considerations for live reloading or broader ideas of watch functionality as an "interactive mode" (<a href="https://github.com/rust-lang/cargo/issues/9339#issuecomment-3340096325">example</a>) as <a href="https://blog.rust-lang.org/inside-rust/2025/10/01/this-development-cycle-in-cargo-1.90/#all-hands-cargo-explain">discussed earlier</a>. Presenting serve/watch as an "interactive mode" can help set expectations when it comes to production use.</p> <p>A challenge with this is the support burden this could put on the Cargo team, which includes supporting users through unmet expectations and feature creep. For example, mdbook has <a href="https://github.com/rust-lang/mdBook/issues/?q=is%3Aissue%20state%3Aopen%20label%3ACommand-serve">several issues</a> open related to its <code>serve</code> functionality.</p> <p><code>rustup doc</code> also has similar needs and it would be good for this effort to be coordinated with them ( <a href="https://github.com/rust-lang/rustup/issues/2151">rustup#2151</a>, <a href="https://github.com/rust-lang/rustup/issues/3112">rustup#3112</a> ).</p> <p>Possible paths forward include experimenting with this as a nightly-only feature or creating a third-party subcommand to experiment with the full blown interactive mode.</p> <h3 id="multi-line-messages-from-build-scripts"><a class="anchor" href="#multi-line-messages-from-build-scripts" aria-hidden="true"></a> Multi-line messages from build scripts</h3> <p><a href="https://github.com/kornelski">kornelski</a> and <a href="https://github.com/ratmice">ratmice</a> started back up the conversation on multi-line build script errors and warnings.</p> <p>Build scripts communicate to cargo through <a href="https://doc.rust-lang.org/cargo/reference/build-scripts.html#outputs-of-the-build-script">directives</a> of the format <code>cargo::&lt;name&gt;=&lt;params&gt;\n</code>, including <code>cargo::warning=&lt;message&gt;\n</code> and <code>cargo::error=&lt;message&gt;\n</code>. The only way to report multiple lines of text for the same message is to split the message across multiple of these directives, causing each line to render as <code>error: &lt;name&gt;@&lt;ver&gt;: &lt;line&gt;</code>. <a href="https://github.com/epage">epage</a> wrote up a <a href="https://github.com/rust-lang/cargo/issues/13233#issuecomment-3185855839">summary</a>, got input, and brought this before the Cargo team.</p> <p>The options includes:</p> <pre class="z-code"><code><span class="z-text z-plain"># Concatenation </span><span class="z-text z-plain">cargo::error=header </span><span class="z-text z-plain">cargo::error+=second line </span><span class="z-text z-plain"> </span><span class="z-text z-plain"># Block start/end </span><span class="z-text z-plain">cargo::error_start= </span><span class="z-text z-plain">header </span><span class="z-text z-plain">second line </span><span class="z-text z-plain">cargo::error_end= </span><span class="z-text z-plain"> </span><span class="z-text z-plain"># Line-count prefix </span><span class="z-text z-plain">cargo::error_start=2 </span><span class="z-text z-plain">header </span><span class="z-text z-plain">second line </span><span class="z-text z-plain"> </span><span class="z-text z-plain"># Block start/end + line prefix </span><span class="z-text z-plain">cargo::error_start= </span><span class="z-text z-plain">cargo::error=header </span><span class="z-text z-plain">cargo::error=second line </span><span class="z-text z-plain">cargo::error_end= </span></code></pre> <!-- 2025-08-18 --> <p>When the team stepped through the options, we determined that our values for a solution include:</p> <ul> <li>Every line having a <code>cargo::</code> prefix to match with our previous communication that cargo ignores everything else</li> <li>Explicit end-of-message, rather than being inferred <ul> <li>Some felt uncomfortable with a blank line being sufficient to end buffering</li> <li>Some felt uncomfortable with cargo::error and cargo::warning changing their semantics from non-buffered to buffered</li> </ul> </li> <li>Graceful handling of nested content or multi-threaded environments</li> </ul> <p>These values excluded "block start/end" and "line-count prefix" solutions. "Concatenation" and "block start/end + line prefix" have points both for and against them. In the end, we favored the value of "explicit end-of-message" and preferred "block start/end + line prefix".</p> <p>There are still <a href="https://github.com/rust-lang/cargo/issues/13233#issuecomment-3201200381">open questions</a>, though we didn't feel strongly whether those needed to be resolved before implementation or during the stabilization process.</p> <h3 id="forgetting-cargo-fmt-after-cargo-fix"><a class="anchor" href="#forgetting-cargo-fmt-after-cargo-fix" aria-hidden="true"></a> Forgetting <code>cargo fmt</code> after <code>cargo fix</code></h3> <!-- team meeting 2025-03-11 --> <p><code>cargo fix</code> and <code>cargo clippy --fix</code> will apply suggested fixes from lints. However, the output is not always pretty and making it so would be difficult. If you are like me, it's easy to not notice that <code>cargo fmt</code> is needed until you see CI fail. It would help if <code>cargo fix</code> also handled formatting (<a href="https://github.com/rust-lang/cargo/issues/12608">#12608</a>).</p> <p>One problem is users may not be using <code>cargo fmt</code> and having <code>cargo fix</code> apply it for the first time could be unwanted on its own and hide the actual fix that went in.</p> <p>A way to reduce unwanted edits is if we had an interface to tell <code>cargo fmt</code> to only re-format the parts changed by <code>cargo fix</code>. The exact interaction for these would have to be carefully considered and may still produce unwanted reformatting.</p> <p>At the next level, Cargo could have a <a href="https://doc.rust-lang.org/cargo/reference/config.html"><code>.cargo/config.toml</code></a> field</p> <pre class="z-code"><code><span class="z-text z-plain">[fix] </span><span class="z-text z-plain">rustfmt = true </span></code></pre> <p>If we did this, we may want to have Cargo run <code>cargo fmt --check</code> first, similar to our "VCS dirty" check.</p> <p>At a minimum, <code>cargo fix</code> could recommend running <code>cargo fmt</code> if changes were made.</p> <p>Our discussion was inconclusive and we moved it to <a href="https://internals.rust-lang.org/t/properly-formatted-cargo-fix-code/22539">Internals</a>.</p> <h3 id="recursively-find-dependencies-at-a-path"><a class="anchor" href="#recursively-find-dependencies-at-a-path" aria-hidden="true"></a> Recursively find dependencies at a <code>path</code></h3> <!-- team meeting 2025-03-11 --> <p>Cargo will automatically find a package within its git repo, like:</p> <pre data-lang="toml" class="language-toml z-code"><code class="language-toml" data-lang="toml"><span class="z-source z-toml"><span class="z-punctuation z-definition z-table z-begin z-toml">[</span><span class="z-meta z-tag z-table z-toml"><span class="z-entity z-name z-table z-toml">dependencies</span></span><span class="z-punctuation z-definition z-table z-end z-toml">]</span> </span><span class="z-source z-toml"><span class="z-meta z-tag z-key z-toml"><span class="z-entity z-name z-tag z-toml">bevy_math</span></span> <span class="z-punctuation z-definition z-key-value z-toml">=</span> <span class="z-punctuation z-definition z-inline-table z-begin z-toml">{</span> <span class="z-meta z-tag z-key z-toml"><span class="z-entity z-name z-tag z-toml">git</span></span> <span class="z-punctuation z-definition z-key-value z-toml">=</span> <span class="z-string z-quoted z-double z-basic z-toml"><span class="z-punctuation z-definition z-string z-begin z-toml">&quot;</span>https://github.com/bevyengine/bevy.git<span class="z-punctuation z-definition z-string z-end z-toml">&quot;</span></span> <span class="z-punctuation z-definition z-inline-table z-end z-toml">}</span> </span></code></pre> <p>However, the same can't be said for <code>path</code> dependencies where an exact path is needed. Say you cloned Bevy into <code>/Users/epage/Development/bevy</code>, you'd have to depend on it as:</p> <pre data-lang="toml" class="language-toml z-code"><code class="language-toml" data-lang="toml"><span class="z-source z-toml"><span class="z-punctuation z-definition z-table z-begin z-toml">[</span><span class="z-meta z-tag z-table z-toml"><span class="z-entity z-name z-table z-toml">dependencies</span></span><span class="z-punctuation z-definition z-table z-end z-toml">]</span> </span><span class="z-source z-toml"><span class="z-meta z-tag z-key z-toml"><span class="z-entity z-name z-tag z-toml">bevy_math</span></span> <span class="z-punctuation z-definition z-key-value z-toml">=</span> <span class="z-punctuation z-definition z-inline-table z-begin z-toml">{</span> <span class="z-meta z-tag z-key z-toml"><span class="z-entity z-name z-tag z-toml">path</span></span> <span class="z-punctuation z-definition z-key-value z-toml">=</span> <span class="z-string z-quoted z-double z-basic z-toml"><span class="z-punctuation z-definition z-string z-begin z-toml">&quot;</span>/Users/epage/Development/bevy/crates/bevy_math/<span class="z-punctuation z-definition z-string z-end z-toml">&quot;</span></span> <span class="z-punctuation z-definition z-inline-table z-end z-toml">}</span> </span></code></pre> <p>For <code>git</code>, the recursive path search has run into several issues, including:</p> <ul> <li>A performance hit for walking the filesystem on every run and parsing the manifests (<a href="https://github.com/rust-lang/cargo/issues/14395">#14395</a>)</li> <li>Ambiguous package names (<a href="https://github.com/rust-lang/cargo/issues/11858">#11858</a>)</li> <li><del>Non-determinism in package selection when multiple share a name</del>, fixed in <a href="https://github.com/rust-lang/cargo/commit/6c0f14c245406e09c1ed7bda8ff770bdd8c3c54e">#14239</a>)</li> <li><del>Warning about ambiguous package names even when not referenced (<a href="https://github.com/rust-lang/cargo/issues/10752">#10752</a>)</del>, fixed in <a href="https://github.com/rust-lang/cargo/pull/14239">#14239</a></li> <li>Non-fatal error messages for unreferenced packages (<a href="https://github.com/rust-lang/cargo/issues/13724">#13724</a>)</li> </ul> <p>At minimum, we can improve the error message from:</p> <pre class="z-code"><code><span class="z-text z-plain">error: no matching package named `definitely_not_bar` found </span><span class="z-text z-plain">location searched: /Users/eric/Temp/foo/crates/bar </span><span class="z-text z-plain">required by package `foo v0.1.0 (/Users/eric/Temp/foo)` </span></code></pre> <p>to something like:</p> <pre class="z-code"><code><span class="z-text z-plain">error: no matching package named `definitely_not_bar` found at `bar/` </span><span class="z-text z-plain">note: required by package `foo v0.1.0 (/Users/eric/Temp/foo)` </span><span class="z-text z-plain"> </span><span class="z-text z-plain">help: package `definitely_not_bar` exists at `bar/definitely_not_bar/` </span></code></pre> <p>Due to the problems we've had with <code>git</code>, we were hesitant to extend the recursive path search to <code>path</code>. This likely wouldn't be reconsidered until at least <a href="https://github.com/rust-lang/cargo/issues/14395">#14395</a> is addressed. We talked about the idea of caching the relative path inside of the <code>Cargo.lock</code>. If the package is no longer at that path (update of <code>git</code> dependency, user edited the layout at <code>path</code>), Cargo would re-scan for the package. The big hurdle would be plumbing this advisory information from one lockfile, through the resolve, to the next lockfile.</p> <h3 id="include-workspace-license-files-with-cargo-new"><a class="anchor" href="#include-workspace-license-files-with-cargo-new" aria-hidden="true"></a> Include workspace license files with <code>cargo new</code></h3> <!-- team meeting 2025-03-11 --> <p>When you run <code>cargo new</code> in a workspace, it will automatically inherit <code>workspace.package</code> fields and the <code>workspace.lints</code> table. Commonly, license files need to be copied into a package for distribution via <code>cargo publish</code> and it would help if symlinked any license files Cargo found in the workspace root into the package (<a href="https://github.com/rust-lang/cargo/issues/13328">13328</a>).</p> <p>On a mechanics side, there are downsides to symlinking on Windows that could make it a bad policy by default, regardless of the platform <code>cargo new</code> is running on. Copying, always or as a fallback to symlinking failing, has its own drawbacks.</p> <p>We could have a <code>workspace.new-files</code> that <code>cargo new</code> will copy in. It's hard to evaluate a solution like this without better understanding where we might go with templateing (<a href="https://github.com/rust-lang/cargo/issues/5151">#5151</a>).</p> <p>We could have a <code>package.extra-files</code> which <code>cargo publish</code> will copy into the <code>.crate</code> file like it does <code>package.readme</code> when it's outside of the package root. If we made it this general, we'd need to also allow users to specify where the files would go.</p> <p>There is <code>package.license-file</code> which <code>cargo publish</code> will already copy into the <code>.crate</code> file if it is outside the package root, like with <code>package.readme</code>. However, only one file can be specified (<a href="https://github.com/rust-lang/cargo/issues/5933">#5933</a>) because this is intended for a custom license when <code>package.license</code> is insufficient. See also <a href="https://github.com/rust-lang/cargo/issues/8537">#8537</a>, <a href="https://github.com/rust-lang/cargo/issues/9908">#9908</a>, <a href="https://github.com/rust-lang/cargo/issues/9972">#9972</a>. We vaguely discussed a way to map license names, including a custom license identifier, to specific files. <code>cargo publish</code> would then copy these into the package root inside the <code>.crate</code> file. We didn't end up reaching any specific conclusions.</p> <h2 id="misc"><a class="anchor" href="#misc" aria-hidden="true"></a> Misc</h2> <ul> <li><a href="https://github.com/ranger-ross">ranger-ross</a> is experimenting with new <code>build-dir</code> layouts in <a href="https://github.com/rust-lang/cargo/pull/15947">#15947</a> while working to improve how we test it in <a href="https://github.com/rust-lang/cargo/pull/15874">#15874</a></li> </ul> <h2 id="focus-areas-without-progress"><a class="anchor" href="#focus-areas-without-progress" aria-hidden="true"></a> Focus areas without progress</h2> <p>These are areas of interest for Cargo team members with no reportable progress for this development-cycle.</p> <p>Project goals in need of owners</p> <ul> <li><a href="https://rust-lang.github.io/rust-project-goals/2025h2/cargo-build-analysis.html">Prototype Cargo build analysis</a></li> <li><a href="https://rust-lang.github.io/rust-project-goals/2025h2/open-namespaces.html">Open namespaces</a></li> <li><a href="https://rust-lang.github.io/rust-project-goals/2025h2/pub-priv.html">Stabilize public/private dependencies</a></li> </ul> <!-- - [Stabilize cargo-script](https://rust-lang.github.io/rust-project-goals/2025h2/cargo-script.html) - [Rework Cargo Build Dir Layout](https://rust-lang.github.io/rust-project-goals/2025h2/cargo-build-dir-layout.html) - [Prototype a new set of Cargo "plumbing" commands](https://rust-lang.github.io/rust-project-goals/2025h2/cargo-plumbing.html) - [Finish the libtest json output experiment](https://rust-lang.github.io/rust-project-goals/2025h2/libtest-json.html) --> <p>Ready-to-develop:</p> <!-- - [Open namespaces](https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#open-namespaces) - [Auto-generate completions](https://github.com/rust-lang/cargo/issues/6645) - See [clap-rs/clap#3166](https://github.com/clap-rs/clap/issues/3166) --> <!-- Needs design and/or experimentation: --> <p>Planning:</p> <ul> <li><a href="https://github.com/rust-lang/cargo/issues/3126">Disabling of default features</a></li> <li><a href="https://github.com/rust-lang/rfcs/pull/3416">RFC #3416: <code>features</code> metadata</a> <ul> <li><a href="https://github.com/rust-lang/rfcs/pull/3487">RFC #3487: visibility</a> (visibility)</li> <li><a href="https://github.com/rust-lang/rfcs/pull/3486">RFC #3486: deprecation</a></li> <li><a href="https://doc.rust-lang.org/cargo/reference/unstable.html#list-of-unstable-features">Unstable features</a></li> </ul> </li> <li><a href="https://internals.rust-lang.org/t/pre-rfc-mutually-excusive-global-features/19618">Pre-RFC: Global, mutually exclusive features</a></li> <li><a href="https://github.com/rust-lang/rfcs/pull/3553">RFC #3553: Cargo SBOM Fragment</a></li> </ul> <!-- - [OS-native config/cache directories (ie XDG support)](https://github.com/rust-lang/cargo/issues/1734) - [Phase 1 Pre-RFC](https://internals.rust-lang.org/t/pre-rfc-split-cargo-home/19747) --> <h2 id="how-you-can-help"><a class="anchor" href="#how-you-can-help" aria-hidden="true"></a> How you can help</h2> <p>If you have ideas for improving cargo, we recommend first checking <a href="https://github.com/rust-lang/cargo/issues/">our backlog</a> and then exploring the idea on <a href="https://internals.rust-lang.org/c/tools-and-infrastructure/cargo/15">Internals</a>.</p> <p>If there is a particular issue that you are wanting resolved that wasn't discussed here, some steps you can take to help move it along include:</p> <ul> <li>Summarizing the existing conversation (example: <a href="https://github.com/rust-lang/cargo/issues/2644#issuecomment-1489371226">Better support for docker layer caching</a>, <a href="https://github.com/rust-lang/cargo/issues/8728#issuecomment-1610265047">Change in <code>Cargo.lock</code> policy</a>, <a href="https://github.com/rust-lang/cargo/issues/9930#issuecomment-1489089277">MSRV-aware resolver</a> )</li> <li>Document prior art from other ecosystems so we can build on the work others have done and make something familiar to users, where it makes sense</li> <li>Document related problems and solutions within Cargo so we see if we are solving to the right layer of abstraction</li> <li>Building on those posts, propose a solution that takes into account the above information and cargo's compatibility requirements (<a href="https://github.com/rust-lang/cargo/issues/9930#issuecomment-1489269471">example</a>)</li> </ul> <p>We are available to help mentor people for <a href="https://doc.crates.io/contrib/issues.html#issue-status-labels">S-accepted issues</a> on <a href="https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo">zulip</a> and you can talk to us in real-time during <a href="https://github.com/rust-lang/cargo/wiki/Office-Hours">Contributor Office Hours</a>. If you are looking to help with one of the bigger projects mentioned here and are just starting out, <a href="https://doc.crates.io/contrib/process/index.html#working-on-issues">fixing some issues</a> will help familiarize yourself with the process and expectations, making things go more smoothly. If you'd like to tackle something <a href="https://doc.crates.io/contrib/issues.html#issue-status-labels">without a mentor</a>, the expectations will be higher on what you'll need to do on your own.</p> Ed Page 2025-09-30T00:00:00+00:00 2025-09-30T00:00:00+00:00 https://blog.rust-lang.org/inside-rust/2025/09/30/all-hands-2026/ <div style="border: 1px solid var(--yellow); text-align: center; padding: 1em;"> <p>TL;DR: The <strong>Rust All Hands 2026</strong> happens <strong>21–23 May</strong> in <strong>Utrecht, Netherlands</strong>.</p> <p><strong><a href="https://forms.gle/GhkvDSfdBaYHUrRJ7">Register here</a></strong>.</p> </div> <hr /> <p>Last May, more than 150 project members and invited guests came together at the largest in-person collaborative event in the history of the Rust project: the Rust All Hands 2025.</p> <p><img src="https://github.com/user-attachments/assets/1da0da5c-3cb0-48b5-91ae-6f043550969c" alt="A large room full of Rustaceans smiling and cheering" /></p> <p>During two full days, spread over 10 different meeting rooms, both pre-planned and ad-hoc discussions took place on a very wide range of topics. (See <a href="https://docs.google.com/spreadsheets/d/1G07-f2pwAzEztZMpuxcCW3EWFS1pEX4ShNbsg91Qqjw/edit?gid=0#gid=0">schedule</a> and <a href="https://rust-lang.zulipchat.com/#narrow/channel/486433-all-hands-2025/topic/Meeting.20notes!/with/518928628">meeting notes</a>.)</p> <p>Many many long standing issues have been unblocked. Many new ideas were discussed, both small and big. Conflicts were resolved. Plans were made. And many personal connections were formed and improved. ❤</p> <p><img src="https://github.com/user-attachments/assets/7e5c42bc-2cf0-4e15-b69c-450264ef6e1d" alt="Jyn hosting a discussion in an open space with plants and some TVs on the wall" /></p> <p>Additionally, several Rust project members gave <a href="https://www.youtube.com/playlist?list=PL8Q1w7Ff68DBJsobwUVTr_vbb2MbxisAF">talks</a> to other project members and contributors, as part of the "Rust Project Track" at the RustWeek conference.</p> <p><img src="https://github.com/user-attachments/assets/b4287c7f-5813-4ec0-bf7f-bde4fd17202d" alt="Michael Goulet (aka compiler-errors) giving a talk with a large projection of a code editor behind" /></p> <p>The feedback from the participants was overwhelmingly positive with an average score of 9.5/10. The vast majority would like this to happen again next year, which is exactly what is happening!</p> <h2 id="rust-all-hands-2026"><a class="anchor" href="#rust-all-hands-2026" aria-hidden="true"></a> Rust All Hands 2026</h2> <p>The Rust All Hands 2026 will again take place in <strong>Utrecht, the Netherlands</strong> as part of <a href="https://2026.rustweek.org/">Rust Week 2026</a>, hosted by <a href="https://2026.rustweek.org/about/">RustNL</a>. The RustWeek conference takes place on Tuesday (19 May) and Wednesday (20 May) followed by the <em>three-day</em> Rust All Hands on <strong>Thursday (21 May), Friday (22 May) and Saturday (23 May)</strong>!</p> <p>The second conference day (Wednesday 20 May) will again include a "Rust Project Track", where Rust team members can give talks to other team members and current and future contributors.</p> <p>If you are interested in being part of the Rust All Hands 2026, please <a href="https://forms.gle/GhkvDSfdBaYHUrRJ7">register your interest here</a>.</p> <p>We'll be sending out formal invitations at a later point in time.</p> <p>If you have any questions, please reach out to Mara on Zulip.</p> <p>See you in Utrecht!</p> Mara Bos 2025-09-23T00:00:00+00:00 2025-09-23T00:00:00+00:00 https://blog.rust-lang.org/inside-rust/2025/09/23/leadership-council-repr-selection/ <p>The September 2025 selections for <a href="https://www.rust-lang.org/governance/teams/leadership-council">Leadership Council</a> representatives have been finalized. The <a href="https://www.rust-lang.org/governance/teams/infra">infrastructure team</a> has chosen <a href="https://github.com/Kobzol/">Jakub Beránek</a> as their new representative. <a href="https://github.com/traviscross/">TC</a>, <a href="https://github.com/m-ou-se">Mara Bos</a>, and <a href="https://github.com/oli-obk">Oli Scherer</a> will continue to represent <a href="https://www.rust-lang.org/governance/teams/lang">lang</a>, <a href="https://www.rust-lang.org/governance/teams/library">libs</a>, and <a href="https://www.rust-lang.org/governance/teams/moderation">mods</a> respectively.</p> <p>We'd like to give our thanks to outgoing representative <a href="https://github.com/Mark-Simulacrum">Mark Rousskov</a> for being instrumental to the formation of the Council and representing the infrastructure team these past two years. We've greatly appreciated Mark's support!</p> <p>Thanks to everyone who participated in the process! The next representative selections will be in March 2026 for the other half of the Council.</p> Eric Huss 2025-09-22T00:00:00+00:00 2025-09-22T00:00:00+00:00 https://blog.rust-lang.org/inside-rust/2025/09/22/variadic-generics-micro-survey/ <p>We are launching a <a href="https://www.surveyhero.com/c/rust-variadic-generics-survey">Variadic Generics Micro Survey</a>.</p> <p>This survey is meant to gather sentiment and use-cases for upcoming design discussions for adding <a href="https://poignardazur.github.io/2021/01/30/variadic-generics/">variadic generics</a> to the Rust language. Its main goal is to answer questions like "What do people think about variadic generics in Rust? How would people use them?". The answers will likely be used to provide more context for an upcoming RFC for variadic generics.</p> <p>The survey is only offered in the English language.</p> <p>We invite you to take this survey even if you have limited Rust experience, or you're not familiar at all with the concept of variadic generics. Every data point helps up paint a clearer picture.</p> <p><strong>You can fill out the survey <a href="https://www.surveyhero.com/c/rust-variadic-generics-survey">here</a>.</strong></p> <p>Filling the survey should take you approximately 5 minutes, and the survey is fully anonymous. We will accept submissions until <strong>Monday, October 20th, 2025</strong>.</p> <p>Please help us spread the word by sharing the survey link via your social networks, at meetups, with colleagues, and in any other community that makes sense to you.</p> <p>Thank you!</p> Olivier Faure 2025-09-11T00:00:00+00:00 2025-09-11T00:00:00+00:00 https://blog.rust-lang.org/inside-rust/2025/09/11/program-management-update-2025-08/ <h1 id="program-management-update-august-2025"><a class="anchor" href="#program-management-update-august-2025" aria-hidden="true"></a> Program management update — August 2025</h1> <p>Quite a lot has happened in August. Let's dive in!</p> <h2 id="leadership-council"><a class="anchor" href="#leadership-council" aria-hidden="true"></a> Leadership Council</h2> <p>Representatives are now being selected for the Rust Leadership Council, and this is as good a time as any to remind everyone what it does.</p> <p>The Council is composed of Project members, one for each <a href="https://www.rust-lang.org/governance">top-level team</a> and its subteams. They <a href="https://github.com/rust-lang/leadership-council/blob/main/roles/council-representative.md">represent the interests of their teams and support the long-term success of the Project as a whole</a>.</p> <p>They also coordinate with the Foundation and elect the Project Directors on the Foundation's board (more on this later).</p> <p>Their work largely happens publicly in <a href="https://github.com/rust-lang/leadership-council/issues">the Council's repository</a>.</p> <p>The representatives meet every other Friday and link these issues in their agenda. When they make a decision, they summarize the discussion and propose an FCP (final comment period) on the relevant issue. As with all FCPs in the Project, they're interested in any feedback people have until the comment period is closed. They review it all.</p> <p>If you want to see what the Council is up to, these issues are a great complement to the <a href="https://github.com/rust-lang/leadership-council/tree/main/minutes/sync-meeting">Council meeting minutes</a> I'm taking and publishing on their behalf.</p> <p>To see this in practice, here is a proposal to send me to the annual <a href="https://kangrejos.com/">Rust for Linux workshop (Kangrejos)</a>:</p> <p><a href="https://github.com/rust-lang/leadership-council/issues/217">https://github.com/rust-lang/leadership-council/issues/217</a></p> <h3 id="representative-selections"><a class="anchor" href="#representative-selections" aria-hidden="true"></a> Representative selections</h3> <p>Every six month, half of the Council's term ends. For this round, the Infra, Lang, Libs, and Mods teams are selecting representatives, and the nominations are now open.</p> <p>If you want to learn more or you're interested in representing your team, please read <a href="https://blog.rust-lang.org/inside-rust/2025/08/15/leadership-council-repr-selection/">Eric Huss's post announcing the selection</a>.</p> <h2 id="rust-foundation-project-directors-2025"><a class="anchor" href="#rust-foundation-project-directors-2025" aria-hidden="true"></a> Rust Foundation Project Directors 2025</h2> <p>This fall, <a href="https://blog.rust-lang.org/inside-rust/2025/08/20/electing-new-project-directors-2025/">we're also looking for new Project Directors</a>.</p> <p>The Directors have staggered terms as well and half are up for election every year.</p> <p>This time it's Santiago Pastorino, Scott McMurray, and Jakob Degen's. None are seeking reelection.</p> <p>These are seats directly on the Rust Foundation board. The Project directors serve the interest of the Rust Project as a whole and sit alongside the Member Directors who represent companies funding the Foundation.</p> <p>Each resolution the Foundation passes must be approved by <em>both</em> Member and Project Directors separately. That means regardless of the size of the board, the Project has an equal voice in Foundation matters.</p> <p>You can nominate yourself or another person until 2025-09-18. Please <a href="https://blog.rust-lang.org/inside-rust/2025/08/20/electing-new-project-directors-2025/">read the blog post for more information</a>. The Project is always looking for fresh faces and diverse voices.</p> <p>I am the <a href="https://github.com/rust-lang/leadership-council/blob/main/policies/project-directorship/election-process.md#setup">facilitator of the selection process</a> this time around. That means I've authored the blog post above, proposed the timeline, and I'll seek out consent and statements from the nominees. I've also announced the election on Zulip as well as an email that should reach all Project members. I'll see it all through, including facilitating the actual election process.</p> <h2 id="bevy-gamedev-followup"><a class="anchor" href="#bevy-gamedev-followup" aria-hidden="true"></a> Bevy/gamedev followup</h2> <p>A month ago, the Lang team invited the <a href="https://bevy.org/">Bevy game engine folks</a> to talk about issues faced by their new users as well as any pain points their project is facing.</p> <p>There were two big topics they mentioned: reflection and variadic generics.</p> <p>Both have been requested for a long time, and the interest is much broader than just Bevy or even just the game development space.</p> <h3 id="reflection"><a class="anchor" href="#reflection" aria-hidden="true"></a> Reflection</h3> <p>Reflection is a mechanism that lets your program look at any type and understand it: getting its name, fields, and <em>their names and types</em> while your program is running. This is in contrast to the <code>derive</code> macro or trait bounds that are processed at compile time.</p> <p>Projects like Bevy currently rely on <code>derive</code> macros. For example, pretty much all its types have <code>derive(Reflect)</code> to provide dynamic field access and type inspection, serialization/deserialization, and scripting. While the usage is simple, these macros are difficult to write and debug. And the language has limitations on where they can be applied.</p> <p>You can only implement a trait for a type (which is what <code>derive</code> does, under the hood) if either the trait or type is <em>defined</em> in the crate you're implementing it in (this is the <a href="https://doc.rust-lang.org/book/ch10-02-traits.html#implementing-a-trait-on-a-type">orphan rule</a>).</p> <p>So if you want to implement <code>Reflect</code> (defined in <a href="https://crates.io/crates/bevy_reflect">bevy_reflect</a>, not your crate), you could derive it for your custom type, but not e.g. for <a href="https://doc.rust-lang.org/std/time/struct.Duration.html"><code>Duration</code></a> or <code>[f32; 2]</code> because they're defined in the standard library.</p> <p>You have to create a new <code>enum</code>/<code>struct</code> that wraps that type and implement the trait yourself. This all gets very complex very quickly and no good solution exists right now.</p> <p>In practice, projects like serde and Bevy often provide implementations for common standard library types (including tuples up to a limited size). But when a new crate comes along, it either has to implement all the useful traits in the ecosystem, convince everyone in the ecosystem to provide the implementations for its types, or accept being less useful than the existing crates. This can lead to ecosystem stagnation.</p> <p>With reflection, a lot of this machinery would be available on every type everywhere and everyone could use it.</p> <p>Oli opened the <a href="https://rust-lang.github.io/rust-project-goals/2025h2/reflection-and-comptime.html">reflection and comptime goal</a> for the 2025H2 period that will build the initial functionality and extend it later on.</p> <p>This happened with little intervention on my part, but I made sure that the Bevy folks were aware (they were!), and I'll be keeping an eye on this to help move it forward and be on the lookout for other projects that may find this useful.</p> <h3 id="variadic-generics"><a class="anchor" href="#variadic-generics" aria-hidden="true"></a> Variadic generics</h3> <p>Remember how I said crates implement traits for tuples up to a certain size? That's a limitation of Rust that is -- again -- felt in many different areas.</p> <p>The basic idea is: suppose you have a tuple of types that all implement a given trait. You want the tuple to be able to implement that trait too.</p> <p>For example, if all the elements of a tuple implement the <a href="https://doc.rust-lang.org/std/fmt/trait.Debug.html"><code>Debug</code></a> trait, you should be able to <code>dbg!()</code> or <code>println!("{:?}", ...)</code> such a tuple.</p> <p>And you can!</p> <pre data-lang="rust" class="language-rust z-code"><code class="language-rust" data-lang="rust"><span class="z-source z-rust"><span class="z-meta z-function z-rust"><span class="z-meta z-function z-rust"><span class="z-storage z-type z-function z-rust">fn</span> </span><span class="z-entity z-name z-function z-rust">main</span></span><span class="z-meta z-function z-rust"><span class="z-meta z-function z-parameters z-rust"><span class="z-punctuation z-section z-parameters z-begin z-rust">(</span></span><span class="z-meta z-function z-rust"><span class="z-meta z-function z-parameters z-rust"><span class="z-punctuation z-section z-parameters z-end z-rust">)</span></span></span></span><span class="z-meta z-function z-rust"> </span><span class="z-meta z-function z-rust"><span class="z-meta z-block z-rust"><span class="z-punctuation z-section z-block z-begin z-rust">{</span> </span></span></span><span class="z-source z-rust"><span class="z-meta z-function z-rust"><span class="z-meta z-block z-rust"> <span class="z-storage z-type z-rust">let</span> tuple <span class="z-keyword z-operator z-assignment z-rust">=</span> <span class="z-meta z-group z-rust"><span class="z-punctuation z-section z-group z-begin z-rust">(</span><span class="z-constant z-numeric z-integer z-decimal z-rust">1</span><span class="z-punctuation z-separator z-rust">,</span> <span class="z-constant z-numeric z-integer z-decimal z-rust">2</span><span class="z-punctuation z-separator z-rust">,</span> <span class="z-constant z-numeric z-integer z-decimal z-rust">3</span><span class="z-punctuation z-separator z-rust">,</span> <span class="z-constant z-numeric z-integer z-decimal z-rust">4</span><span class="z-punctuation z-separator z-rust">,</span> <span class="z-constant z-numeric z-integer z-decimal z-rust">5</span><span class="z-punctuation z-separator z-rust">,</span> <span class="z-constant z-numeric z-integer z-decimal z-rust">6</span><span class="z-punctuation z-separator z-rust">,</span> <span class="z-constant z-numeric z-integer z-decimal z-rust">7</span><span class="z-punctuation z-separator z-rust">,</span> <span class="z-constant z-numeric z-integer z-decimal z-rust">8</span><span class="z-punctuation z-separator z-rust">,</span> <span class="z-constant z-numeric z-integer z-decimal z-rust">9</span><span class="z-punctuation z-separator z-rust">,</span> <span class="z-constant z-numeric z-integer z-decimal z-rust">10</span><span class="z-punctuation z-separator z-rust">,</span> <span class="z-constant z-numeric z-integer z-decimal z-rust">11</span><span class="z-punctuation z-separator z-rust">,</span> <span class="z-constant z-numeric z-integer z-decimal z-rust">12</span></span><span class="z-meta z-group z-rust"><span class="z-punctuation z-section z-group z-end z-rust">)</span></span><span class="z-punctuation z-terminator z-rust">;</span> </span></span></span><span class="z-source z-rust"><span class="z-meta z-function z-rust"><span class="z-meta z-block z-rust"> <span class="z-support z-macro z-rust">println!</span><span class="z-meta z-group z-rust"><span class="z-punctuation z-section z-group z-begin z-rust">(</span></span><span class="z-meta z-group z-rust"><span class="z-string z-quoted z-double z-rust"><span class="z-punctuation z-definition z-string z-begin z-rust">&quot;</span><span class="z-constant z-other z-placeholder z-rust">{tuple:?}</span><span class="z-punctuation z-definition z-string z-end z-rust">&quot;</span></span></span><span class="z-meta z-group z-rust"><span class="z-punctuation z-section z-group z-end z-rust">)</span></span><span class="z-punctuation z-terminator z-rust">;</span> </span></span></span><span class="z-source z-rust"><span class="z-meta z-function z-rust"><span class="z-meta z-block z-rust"></span><span class="z-meta z-block z-rust"><span class="z-punctuation z-section z-block z-end z-rust">}</span></span></span> </span><span class="z-source z-rust"> </span><span class="z-source z-rust"><span class="z-comment z-line z-double-slash z-rust"><span class="z-punctuation z-definition z-comment z-rust">//</span> (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12) </span></span></code></pre> <p>(<a href="https://play.rust-lang.org/?version=stable&amp;mode=debug&amp;edition=2024&amp;gist=88ec1f7ff90a07da8a0c9852c81594ce">playground</a>)</p> <p>...sort of:</p> <pre data-lang="rust" class="language-rust z-code"><code class="language-rust" data-lang="rust"><span class="z-source z-rust"><span class="z-meta z-function z-rust"><span class="z-meta z-function z-rust"><span class="z-storage z-type z-function z-rust">fn</span> </span><span class="z-entity z-name z-function z-rust">main</span></span><span class="z-meta z-function z-rust"><span class="z-meta z-function z-parameters z-rust"><span class="z-punctuation z-section z-parameters z-begin z-rust">(</span></span><span class="z-meta z-function z-rust"><span class="z-meta z-function z-parameters z-rust"><span class="z-punctuation z-section z-parameters z-end z-rust">)</span></span></span></span><span class="z-meta z-function z-rust"> </span><span class="z-meta z-function z-rust"><span class="z-meta z-block z-rust"><span class="z-punctuation z-section z-block z-begin z-rust">{</span> </span></span></span><span class="z-source z-rust"><span class="z-meta z-function z-rust"><span class="z-meta z-block z-rust"> <span class="z-storage z-type z-rust">let</span> tuple <span class="z-keyword z-operator z-assignment z-rust">=</span> <span class="z-meta z-group z-rust"><span class="z-punctuation z-section z-group z-begin z-rust">(</span><span class="z-constant z-numeric z-integer z-decimal z-rust">1</span><span class="z-punctuation z-separator z-rust">,</span> <span class="z-constant z-numeric z-integer z-decimal z-rust">2</span><span class="z-punctuation z-separator z-rust">,</span> <span class="z-constant z-numeric z-integer z-decimal z-rust">3</span><span class="z-punctuation z-separator z-rust">,</span> <span class="z-constant z-numeric z-integer z-decimal z-rust">4</span><span class="z-punctuation z-separator z-rust">,</span> <span class="z-constant z-numeric z-integer z-decimal z-rust">5</span><span class="z-punctuation z-separator z-rust">,</span> <span class="z-constant z-numeric z-integer z-decimal z-rust">6</span><span class="z-punctuation z-separator z-rust">,</span> <span class="z-constant z-numeric z-integer z-decimal z-rust">7</span><span class="z-punctuation z-separator z-rust">,</span> <span class="z-constant z-numeric z-integer z-decimal z-rust">8</span><span class="z-punctuation z-separator z-rust">,</span> <span class="z-constant z-numeric z-integer z-decimal z-rust">9</span><span class="z-punctuation z-separator z-rust">,</span> <span class="z-constant z-numeric z-integer z-decimal z-rust">10</span><span class="z-punctuation z-separator z-rust">,</span> <span class="z-constant z-numeric z-integer z-decimal z-rust">11</span><span class="z-punctuation z-separator z-rust">,</span> <span class="z-constant z-numeric z-integer z-decimal z-rust">12</span><span class="z-punctuation z-separator z-rust">,</span> <span class="z-constant z-numeric z-integer z-decimal z-rust">13</span></span><span class="z-meta z-group z-rust"><span class="z-punctuation z-section z-group z-end z-rust">)</span></span><span class="z-punctuation z-terminator z-rust">;</span> </span></span></span><span class="z-source z-rust"><span class="z-meta z-function z-rust"><span class="z-meta z-block z-rust"> <span class="z-support z-macro z-rust">println!</span><span class="z-meta z-group z-rust"><span class="z-punctuation z-section z-group z-begin z-rust">(</span></span><span class="z-meta z-group z-rust"><span class="z-string z-quoted z-double z-rust"><span class="z-punctuation z-definition z-string z-begin z-rust">&quot;</span><span class="z-constant z-other z-placeholder z-rust">{tuple:?}</span><span class="z-punctuation z-definition z-string z-end z-rust">&quot;</span></span></span><span class="z-meta z-group z-rust"><span class="z-punctuation z-section z-group z-end z-rust">)</span></span><span class="z-punctuation z-terminator z-rust">;</span> </span></span></span><span class="z-source z-rust"><span class="z-meta z-function z-rust"><span class="z-meta z-block z-rust"></span><span class="z-meta z-block z-rust"><span class="z-punctuation z-section z-block z-end z-rust">}</span></span></span> </span><span class="z-source z-rust"> </span><span class="z-source z-rust"><span class="z-comment z-line z-double-slash z-rust"><span class="z-punctuation z-definition z-comment z-rust">//</span> error[E0277]: `({integer}, [...], {integer})` doesn&#39;t implement `Debug` </span></span><span class="z-source z-rust"><span class="z-comment z-line z-double-slash z-rust"><span class="z-punctuation z-definition z-comment z-rust">//</span> --&gt; src/main.rs:3:16 </span></span><span class="z-source z-rust"><span class="z-comment z-line z-double-slash z-rust"><span class="z-punctuation z-definition z-comment z-rust">//</span> [...] </span></span><span class="z-source z-rust"> </span></code></pre> <p>(<a href="https://play.rust-lang.org/?version=stable&amp;mode=debug&amp;edition=2024&amp;gist=245a91abb5ac3162bb537428e348fd02">playground</a>)</p> <p>Even in the Rust standard library, traits like this are <a href="https://doc.rust-lang.org/std/primitive.tuple.html#trait-implementations-1">only implemented for tuples up to 12 elements</a>.</p> <p>This is, again, keenly felt by anyone writing an entity component system (ECS) or object-relational mapping (ORM) and in particular their query systems.</p> <p>Some time ago, Olivier Faure took up the mantle and drove the discussions at the last two RustWeek conferences (read the <a href="https://poignardazur.github.io/2024/05/25/report-on-rustnl-variadics/">2024</a> and <a href="https://poignardazur.github.io/2025/06/07/report-on-variadics-rustweek/">2025</a> reports).</p> <p>Olivier also wrote <a href="https://poignardazur.github.io/2025/07/09/variadic-generics-dead-ends/">"Variadic Generics ideas that won't work for Rust"</a> which highlights the many pitfals even the simplest "why don't we just..." ideas inevitably run into. This is a complex feature that touches a lot of Rust's machinery, and it can't be added in easily.</p> <p>But we still want it!</p> <p>Some of the things blocking this in the past have either been resolved or are going to be resolved soon (e.g. the <a href="https://rustc-dev-guide.rust-lang.org/solve/trait-solving.html">new trait type solver</a>). And the Lang team is interested in reviewing a proposal.</p> <p>I've done a lot of background reading (which made me appreciate the complexity), talked to Olivier and Alice Cecile, and <a href="https://github.com/rust-lang/lang-team/issues/348">opened a design meeting on the Lang side</a> as there is a way forward now.</p> <p>The next steps are getting an RFC written and scheduling the design meeting. I'm again on the lookout for other people interested in the space (either with proposals of their own or usecases we want to make sure are heard) so I can point them to this space.</p> <h2 id="lori-lorusso-foundation-director-of-outreach"><a class="anchor" href="#lori-lorusso-foundation-director-of-outreach" aria-hidden="true"></a> Lori Lorusso: Foundation Director of Outreach</h2> <p>Earlier this month, <a href="https://rustfoundation.org/about/#lori-lorusso-director-of-outreach">Lori</a> joined the Rust Foundation.</p> <p>She'll be overseeing the grants program as well as the external outreach and internal inreach and communication. She'll also look at bringing in communities and people from areas that we haven't reached yet.</p> <p>As our roles overlap a bit (and can definitely benefit from our collaboration -- e.g. on the communication between the Project and Foundation), we've set up a regular check-in.</p> <p>One of the near-term things I'll do is get her onboarded on <a href="https://blog.rust-lang.org/">the Rust blog</a> system so she can publish posts there.</p> <h2 id="content-team"><a class="anchor" href="#content-team" aria-hidden="true"></a> Content team</h2> <p>This month also saw a formation of a <a href="https://www.rust-lang.org/governance/teams/launching-pad#team-content">new team</a> focused on producing audio/video/text content about Rust and people working on it and with it. These can be interviews, podcasts, etc.</p> <p>TC and Pete LeVasseur are the leads, and we also have Cameron Dershem, Xander Cesari, Tyler Mandry, Lori, and yours truly.</p> <p>We already have a few interviews planned for <a href="https://rustconf.com/">RustConf 2025</a>.</p> <p>Here's the <a href="https://github.com/rust-lang/leadership-council/issues/206">Content Team's charter</a>. Forming a new "pseudo top-level team" like this is something you propose to the Leadership Council in their repo's issues. It then gets discussed at their meeting and decided on using the FCP process.</p> <h2 id="build-std"><a class="anchor" href="#build-std" aria-hidden="true"></a> build-std</h2> <p><a href="https://rust-lang.github.io/rust-project-goals/2025h2/build-std.html">build-std</a> is an ongoing initiative to provide a blessed, stable process for building the Rust standard library you can use instead of the one we provide.</p> <p>There are many different motivations for this, for example supporting platforms where Rust doesn't ship a precompiled library, optimizing it to known hardware or reducing its size (by e.g. removing features that are not necessary). This is of interest to the <a href="https://rust-for-linux.com/">Rust for Linux project</a>, among others.</p> <p>David Wood and Adam Gemmell wrote a comprehensive document describing its history, motivations, and past experiments, and they made a proposal for a minimal solution that they can start building.</p> <p>This has been regularly reviewed by a handful of people across the relevant teams. After many rounds of feedback, David feels the proposal is solid enough to open to a broader group.</p> <p>He's shared it with more representatives from the Libs, crates.io, bootstrap, infra, compiler, and Cargo teams, as well as with members of the embedded working group. He's also shared it with non-Cargo users e.g. the Rust for Linux folks (who are interested in building std without Cargo).</p> <p>Once this next round settles down, he will open the RFC (it will likely be several documents each focusing on a different stage of the effort).</p> <h2 id="rust-for-linux"><a class="anchor" href="#rust-for-linux" aria-hidden="true"></a> Rust for Linux</h2> <p><a href="https://rust-for-linux.com/">Rust for Linux</a> is an ongoing initiative to be able to write Linux kernel code in Rust. The motivations include memory safety and that a modern language may help to bring in more contributors.</p> <p>The focus in this second half of 2025 is to bring the unstable features RfL is using into stable Rust. Like Rust itself, Linux takes stability and backwards compatibility seriously. Building on stable Rust in the right fit.</p> <h3 id="rfc-pass-pointers-to-const"><a class="anchor" href="#rfc-pass-pointers-to-const" aria-hidden="true"></a> RFC: Pass pointers to <code>const</code></h3> <p>Rust has support for <a href="https://doc.rust-lang.org/nightly/rust-by-example/unsafe/asm.html">inline assembly</a>. This lets you do things the language doesn't have direct support for such as accessing CPU registers or reading/writing values to device-specific segments in memory to control their behavior (this is often used when writing drivers).</p> <p>The <code>asm!</code> macro lets you interpolate constant values into the assembly code you've written, similar to how you can interpolate values into a format string:</p> <pre data-lang="rust" class="language-rust z-code"><code class="language-rust" data-lang="rust"><span class="z-source z-rust"><span class="z-support z-macro z-rust">println!</span><span class="z-meta z-group z-rust"><span class="z-punctuation z-section z-group z-begin z-rust">(</span></span><span class="z-meta z-group z-rust"><span class="z-string z-quoted z-double z-rust"><span class="z-punctuation z-definition z-string z-begin z-rust">&quot;</span>The meaning of life, universe and everything: <span class="z-constant z-other z-placeholder z-rust">{}</span><span class="z-punctuation z-definition z-string z-end z-rust">&quot;</span></span></span><span class="z-meta z-group z-rust"><span class="z-punctuation z-separator z-rust">,</span> <span class="z-constant z-numeric z-integer z-decimal z-rust">42</span><span class="z-punctuation z-section z-group z-end z-rust">)</span></span><span class="z-punctuation z-terminator z-rust">;</span> </span></code></pre> <p>But constant values only get you so far. A common thing when writing assembly is to be able to pass <em>pointer</em> values (e.g. pointer to a specific field of a struct you want to manipulate) around. But currently, <a href="https://doc.rust-lang.org/1.89.0/reference/inline-assembly.html#r-asm.operand-type.supported-operands.sym">only integer constant expressions are allowed</a>.</p> <p>Alice Ryhl opened an RFC that <a href="https://github.com/rust-lang/rfcs/pull/3848">allows specifying pointers in the <code>const</code> operand</a> too. Conceptually (and in assembly specifically) pointers could be thought of as just numbers that are interpreted as addresses to memory (although in Rust, the story is far more complex and <a href="https://doc.rust-lang.org/std/ptr/index.html#provenance">pointers are not the same thing as integers</a>).</p> <p>This is now ready for feedback from the Lang team, so I opened a <a href="https://github.com/rust-lang/lang-team/issues/347">design meeting issue</a>, and got it scheduled for review and discussion.</p> <h3 id="field-projections"><a class="anchor" href="#field-projections" aria-hidden="true"></a> Field projections</h3> <p>We also had a design meeting on <a href="https://rust-lang.github.io/rust-project-goals/2025h2/field-projections.html">field projections</a>. When you have a type behind a <code>&amp;</code> or <code>&amp;mut</code> reference, you can access its field "directly" as if the pointer type weren't there:</p> <pre data-lang="rust" class="language-rust z-code"><code class="language-rust" data-lang="rust"><span class="z-source z-rust"><span class="z-meta z-struct z-rust"><span class="z-storage z-type z-struct z-rust">struct</span> </span><span class="z-meta z-struct z-rust"><span class="z-entity z-name z-struct z-rust">Position</span> </span><span class="z-meta z-struct z-rust"><span class="z-meta z-block z-rust"><span class="z-punctuation z-section z-block z-begin z-rust">{</span> </span></span></span><span class="z-source z-rust"><span class="z-meta z-struct z-rust"><span class="z-meta z-block z-rust"> <span class="z-variable z-other z-member z-rust">x</span><span class="z-punctuation z-separator z-type z-rust">:</span> <span class="z-storage z-type z-rust">f32</span>, </span></span></span><span class="z-source z-rust"><span class="z-meta z-struct z-rust"><span class="z-meta z-block z-rust"> <span class="z-variable z-other z-member z-rust">y</span><span class="z-punctuation z-separator z-type z-rust">:</span> <span class="z-storage z-type z-rust">f32</span>, </span></span></span><span class="z-source z-rust"><span class="z-meta z-struct z-rust"><span class="z-meta z-block z-rust"></span><span class="z-meta z-block z-rust"><span class="z-punctuation z-section z-block z-end z-rust">}</span></span></span> </span><span class="z-source z-rust"> </span><span class="z-source z-rust"><span class="z-meta z-impl z-rust"><span class="z-storage z-type z-impl z-rust">impl</span> </span><span class="z-meta z-impl z-rust"><span class="z-entity z-name z-impl z-rust">Position</span> </span><span class="z-meta z-impl z-rust"><span class="z-meta z-block z-rust"><span class="z-punctuation z-section z-block z-begin z-rust">{</span> </span></span></span><span class="z-source z-rust"><span class="z-meta z-impl z-rust"><span class="z-meta z-block z-rust"> <span class="z-meta z-function z-rust"><span class="z-meta z-function z-rust"><span class="z-storage z-type z-function z-rust">fn</span> </span><span class="z-entity z-name z-function z-rust">get_x</span></span><span class="z-meta z-function z-rust"><span class="z-meta z-function z-parameters z-rust"><span class="z-punctuation z-section z-parameters z-begin z-rust">(</span><span class="z-keyword z-operator z-rust">&amp;</span><span class="z-variable z-parameter z-rust">self</span></span><span class="z-meta z-function z-rust"><span class="z-meta z-function z-parameters z-rust"><span class="z-punctuation z-section z-parameters z-end z-rust">)</span></span></span></span><span class="z-meta z-function z-rust"> <span class="z-meta z-function z-return-type z-rust"><span class="z-punctuation z-separator z-rust">-&gt;</span> <span class="z-keyword z-operator z-rust">&amp;</span><span class="z-storage z-type z-rust">f32</span></span> </span><span class="z-meta z-function z-rust"><span class="z-meta z-block z-rust"><span class="z-punctuation z-section z-block z-begin z-rust">{</span> </span></span></span></span></span><span class="z-source z-rust"><span class="z-meta z-impl z-rust"><span class="z-meta z-block z-rust"><span class="z-meta z-function z-rust"><span class="z-meta z-block z-rust"> <span class="z-keyword z-operator z-bitwise z-rust">&amp;</span><span class="z-variable z-language z-rust">self</span><span class="z-punctuation z-accessor z-dot z-rust">.</span>x </span></span></span></span></span><span class="z-source z-rust"><span class="z-meta z-impl z-rust"><span class="z-meta z-block z-rust"><span class="z-meta z-function z-rust"><span class="z-meta z-block z-rust"> </span><span class="z-meta z-block z-rust"><span class="z-punctuation z-section z-block z-end z-rust">}</span></span></span> </span></span></span><span class="z-source z-rust"><span class="z-meta z-impl z-rust"><span class="z-meta z-block z-rust"></span><span class="z-meta z-block z-rust"><span class="z-punctuation z-section z-block z-end z-rust">}</span></span></span> </span></code></pre> <p>The language understands <code>Position</code> is behind a pointer, calculates an offset to the field <code>x</code>, and gives you that pointer back.</p> <p>There's a long list of wrapper types where field access makes sense but where it's not implemented because the semantics are different from the regular <code>Deref/DerefMut</code> traits. For example: <code>MaybeUninit&lt;T&gt;</code>, <code>Pin&lt;P&gt;</code>, <code>Cell&lt;T&gt;</code>, or the raw pointers <code>*const T</code>/<code>*mut T</code>. And of course custom types.</p> <p>Linux uses pinned values (<code>Pin&lt;P&gt;</code> -- values that can't move around in memory), raw pointers, and <code>MaybeUninit</code> all over the place in addition to many custom fields that would greatly benefit from field projections.</p> <p>Benno Lossin, who owns the <a href="https://rust-lang.github.io/rust-project-goals/2025h2/field-projections.html">field projection goal</a>, prepared a <a href="https://hackmd.io/@rust-lang-team/S1I1aEc_lx">design</a> to move this forward as a lang experiment. This was approved; we now have a <a href="https://github.com/rust-lang/rust/issues/145383">field projection tracking issue</a> as well as an <a href="https://github.com/BennoLossin/rust/tree/field-projections">initial implementation</a>.</p> <h3 id="reducing-codegen-size"><a class="anchor" href="#reducing-codegen-size" aria-hidden="true"></a> Reducing codegen size</h3> <p>The last Rust for Linux meeting got into a fascinating discussion about an ongoing need to reduce the size of the binary generated by rustc. There is functionality in the Rust standard library that is not used in the kernel but that still takes up space, e.g. support for 128-bit integer types, the <code>alloc</code> crate, and the floating point formatting code. Some are not relevant while others (like alloc) are reimplemented by Rust for Linux.</p> <p>There's an interest in being able to compile certain features out (using <code>cfg</code>) and/or having a minimal core that projects can build on top of.</p> <p>This is something I plan to gather more information about and follow-up on.</p> <h3 id="kangrejos-2025"><a class="anchor" href="#kangrejos-2025" aria-hidden="true"></a> Kangrejos 2025</h3> <p>Due to their warm invitation, and supported by the council and funding from the Project Priorities budget, I'll be joining the Rust for Linux team at their <a href="https://kangrejos.com/">Kangrejos workshop</a> in Spain in September. I hope to get to know the Rust for Linux people better in a less formal environment, get more hand-on experience with what they're doing and the challenges they're facing, and be the conduit for even more collaboration between them and the Rust Project.</p> <h2 id="conferences"><a class="anchor" href="#conferences" aria-hidden="true"></a> Conferences</h2> <p>September is going to be an <em>eventful</em> (if you pardon the pun) month!</p> <p>First up, <a href="https://rustconf.com/">RustConf 2025</a> took place in Seattle, Washington, USA (from 2025-09-02 to 2025-09-05). RustConf offered virtual tickets so people could attend online as well.</p> <p>Second is the <a href="https://rustcc.cn/2025conf/">RustGlobal China and RustChinaConf 2025</a> in Hangzhou, China (from 2025-09-13 to 2025-09-14)</p> <p>And finally the aforementioned <a href="https://kangrejos.com/">Rust for Linux workshop, Kangrejos</a> in Oviedo, Spain (from from 2025-09-17 to 2025-09-18).</p> <p>If nothing else, look forward to a good batch of talks being posted online in the coming weeks and months!</p> <h2 id="stats"><a class="anchor" href="#stats" aria-hidden="true"></a> Stats</h2> <p>Total words of meeting minutes written: 138.6k (June - August).</p> <p>Meetings attended: 31</p> <p>Total words written: 46k</p> <p>Average (mean) word count per team meeting:</p> <ul> <li>Cargo: 1.9k</li> <li>Lang triage: 2.5k</li> <li>Libs: 5.9k</li> <li>Leadership council: 2.9k</li> </ul> <p>You can see the <a href="https://blog.rust-lang.org/inside-rust/2025/08/05/program-management-update-2025-07/#fun-stats">June and July stats in the previous update</a>.</p> Tomas Sedovic 2025-09-10T00:00:00+00:00 2025-09-10T00:00:00+00:00 https://blog.rust-lang.org/inside-rust/2025/09/10/leadership-council-update/ <p>Hello again from the Rust Leadership Council! We wanted to share an update on what the Council has been working on since <a href="https://blog.rust-lang.org/inside-rust/2025/06/11/leadership-council-update/">our last update</a>.</p> <h2 id="accomplishments-so-far"><a class="anchor" href="#accomplishments-so-far" aria-hidden="true"></a> Accomplishments so far</h2> <h3 id="content-team"><a class="anchor" href="#content-team" aria-hidden="true"></a> Content team</h3> <p>Pete LeVasseur and TC created the <a href="https://www.rust-lang.org/governance/teams/launching-pad#team-content">Content team</a> (<a href="https://github.com/rust-lang/leadership-council/issues/206">leadership-council#206</a>). The team is charged with producing publishable content that is of interest and benefit to the Rust Project and its community including blog posts, videos, podcasts, etc. The team is talking with people in the Project and the community to share their knowledge and experience, and most immediately, the team has been organizing interviews that will be recorded at RustConf.</p> <p>We are looking forward to soon seeing what they produce.</p> <h3 id="all-hands-2026"><a class="anchor" href="#all-hands-2026" aria-hidden="true"></a> All-hands 2026</h3> <p>The Council approved the 2026 All-Hands event (<a href="https://github.com/rust-lang/leadership-council/issues/192">leadership-council#192</a>). This event is an opportunity for Project members to meet in person to to collaborate on the future of Rust. The event is scheduled to occur again with <a href="https://2026.rustweek.org/">RustWeek 2026</a> in The Netherlands on May 21-23. More information will be coming soon.</p> <h3 id="additional-items"><a class="anchor" href="#additional-items" aria-hidden="true"></a> Additional items</h3> <p>And a few other items:</p> <ul> <li>Coordinated with the mods team on the creation of the venue mods team, which is responsible for moderating venues such as GitHub and Zulip. <a href="https://github.com/rust-lang/team/pull/1874">team#1874</a></li> <li>Approved the renewal of the compiler ops contract. <a href="https://github.com/rust-lang/leadership-council/issues/181">leadership-council#181</a></li> <li>Approved substitutes for the July and August Foundation board meetings. <a href="https://github.com/rust-lang/leadership-council/issues/187">leadership-council#187</a> <a href="https://github.com/rust-lang/leadership-council/issues/194">leadership-council#194</a> <a href="https://github.com/rust-lang/leadership-council/issues/201">leadership-council#201</a></li> <li>Coordinated with the RustConf organizers on how to distribute free or reduced-price tickets for Project members. <a href="https://github.com/rust-lang/leadership-council/issues/190">leadership-council#190</a></li> <li>Added <a href="https://github.com/jieyouxu">@jieyouxu</a> to the team-repo-admins, who are responsible for updating the Rust team memberships and resources. <a href="https://github.com/rust-lang/leadership-council/issues/205">leadership-council#205</a></li> <li>Coordinated with the infra team to set up the email alias for <code>contact@rust-lang.org</code> as the contact address of the rust-lang GitHub organization. <a href="https://github.com/rust-lang/leadership-council/issues/202">leadership-council#202</a></li> <li>Coordinated with the social media team to approve the creation of an official LinkedIn page for Rust, now up at <a href="https://www.linkedin.com/company/rust-lang/">https://www.linkedin.com/company/rust-lang/</a>. <a href="https://github.com/rust-lang/leadership-council/issues/208">leadership-council#208</a></li> <li>Approved a travel grant for <a href="https://github.com/tomassedovic">@tomassedovic</a> to go to <a href="https://kangrejos.com/">Kangrejos 2025</a>, the Rust for Linux Workshop. <a href="https://github.com/rust-lang/leadership-council/issues/217">leadership-council#217</a></li> </ul> <h2 id="ongoing-work"><a class="anchor" href="#ongoing-work" aria-hidden="true"></a> Ongoing work</h2> <p>There are various efforts underway on projects that have had significant discussions since the last update, but have not concluded with any decisions, yet. They are:</p> <h3 id="rust-society"><a class="anchor" href="#rust-society" aria-hidden="true"></a> Rust Society</h3> <p><a href="https://github.com/jamesmunns">@JamesMunns</a> has continued to develop the concept of the "Rust Society". The Rust Society will be an organizational structure for user groups (commonly called "Special Interest Groups", "Working Groups", etc. in other organizations) outside of the Rust Project, but administrated by the Rust Project via a new "T-Society-Admins" subteam of the Launching Pad.</p> <p>This structure is intended to be the long-term home for existing Domain Working Groups, which will be retired as a concept after this work is complete. In the future, this structure intends to offer "open enrollment" for any interested group of users.</p> <p>See the latest <a href="https://github.com/rust-lang/leadership-council/issues/159#issuecomment-3237633417">proposed charter</a> for how the Rust Society will function.</p> <h3 id="foundation"><a class="anchor" href="#foundation" aria-hidden="true"></a> Foundation</h3> <p>There have been continual discussions with the Foundation on various topics. We are excited to welcome <a href="https://github.com/LoriLorusso">Lori Lorusso</a>, who has started as the Foundation's new <a href="https://rustfoundation.org/media/welcoming-lori-lorusso-the-rust-foundations-new-director-of-outreach/">Director of Outreach</a>. She hit the ground running and has been helping to coordinate with the Foundation and plan upcoming projects.</p> <p>We have been discussing with the Foundation the possibilities for continuing the budget for <a href="https://github.com/rust-lang/leadership-council/issues/183">project priorities</a> in 2026. For 2024 and 2025, this budget was made possible by a generous unrestricted grant from Microsoft. We are looking for ways that we can continue this budget so as to continue important programs such as travel grants, the all-hands, project grants, <a href="https://github.com/rust-lang/leadership-council/issues/151">program management</a>, and <a href="https://github.com/rust-lang/leadership-council/issues/181">compiler operations</a>.</p> <p>We discussed the condition of the 2025 travel grant budget (<a href="https://github.com/rust-lang/leadership-council/issues/182">leadership-council#182</a>). Many Project members used most of their $2,000 limit during the all-hands earlier this year, and we had concerns that members would not be able to attend other events like RustConf. Ultimately we decided to keep with the current policy and will be working on figuring out what our possible option might be for funding this in 2026.</p> <p>Finally, on the top of our minds is the <a href="https://github.com/rust-lang/leadership-council/issues/197">Foundation three-year strategy</a>. We have a keen interest in working with the Foundation staff to ensure that we are all focused together on the best objectives. We hope to share more on this soon.</p> <h3 id="additional-items-1"><a class="anchor" href="#additional-items-1" aria-hidden="true"></a> Additional items</h3> <ul> <li>We have been discussing a policy for better management of the alumni status of Project members. <a href="https://github.com/rust-lang/leadership-council/pull/218">leadership-council#218</a> <a href="https://github.com/rust-lang/leadership-council/issues/175">leadership-council#175</a></li> <li>We had some discussions on who is responsible for how stable and unstable features relate to the stable releases. <a href="https://github.com/rust-lang/leadership-council/issues/180">leadership-council#180</a></li> <li>The September 2025 council elections have started. <a href="https://github.com/rust-lang/leadership-council/issues/211">leadership-council#211</a></li> <li>The 2025 Foundation director elections have started. <a href="https://github.com/tomassedovic">@tomassedovic</a> will be facilitating this year. <a href="https://blog.rust-lang.org/inside-rust/2025/08/20/electing-new-project-directors-2025/">https://blog.rust-lang.org/inside-rust/2025/08/20/electing-new-project-directors-2025/</a></li> <li>We launched the <a href="https://blog.rust-lang.org/inside-rust/2025/06/30/2025-leadership-council-survey/">2025 Leadership Council Survey</a>, and will be posting the results soon.</li> </ul> <h2 id="following-our-work"><a class="anchor" href="#following-our-work" aria-hidden="true"></a> Following our work</h2> <p>As you can see from the many links above, the work of the Council happens mostly in public on GitHub issues posted in <a href="https://github.com/rust-lang/leadership-council/issues">our repository</a>. The items on our meeting agendas are drawn from these. After discussing an item, we summarize that discussion and any shared <a href="https://aturon.github.io/tech/2018/05/25/listening-part-1/">rationales</a> on the issue. When we make decisions, we propose on the issue a "final comment period" (FCP), and as with all FCPs in the Project, we're interested in and review any feedback that people have before or during this final comment period.</p> <p>To follow our work in real time, watch our repository.</p> <h2 id="meeting-minutes"><a class="anchor" href="#meeting-minutes" aria-hidden="true"></a> Meeting minutes</h2> <p>We publish minutes from all Council meetings to the <a href="https://github.com/rust-lang/leadership-council/tree/main/minutes">Leadership Council repo</a>. Links to the minutes since our last update are:</p> <ul> <li><a href="https://github.com/rust-lang/leadership-council/blob/main/minutes/sync-meeting/2025-06-06.md">June 6, 2025</a></li> <li><a href="https://github.com/rust-lang/leadership-council/blob/main/minutes/sync-meeting/2025-06-20.md">June 20, 2025</a></li> <li><a href="https://github.com/rust-lang/leadership-council/blob/main/minutes/sync-meeting/2025-07-04.md">July 4, 2025</a></li> <li><a href="https://github.com/rust-lang/leadership-council/blob/main/minutes/sync-meeting/2025-07-18.md">July 18, 2025</a></li> <li><a href="https://github.com/rust-lang/leadership-council/blob/main/minutes/sync-meeting/2025-08-08.md">August 8, 2025</a></li> <li><a href="https://github.com/rust-lang/leadership-council/blob/main/minutes/sync-meeting/2025-08-15.md">August 15, 2025</a></li> </ul> Eric Huss 2025-09-04T00:00:00+00:00 2025-09-04T00:00:00+00:00 https://blog.rust-lang.org/inside-rust/2025/09/04/crossing-the-streams/ <p>For those of you who are fans of the original Ghostbusters movie, the phrase, "Who you gonna call? (Ghostbusters)," may be the first thing you think of but I want to focus on the line said by Dr. Peter Venkman, played by the one and only Bill Murray, "Cross the streams!" Originally the Ghostbusters were warned, "Don't cross the streams" — or they would have a total cataclysmic event — but at the end of the movie, to defeat Gozar, they needed to risk everything by crossing the streams, and it worked; Gozar was annihilated and the Ghostbusters (and NYC) survived. You may be thinking, "what does this have to do with the Rust Project or the Rust Foundation?" Don't worry, I got you!</p> <p>As the <a href="https://rustfoundation.org/media/welcoming-lori-lorusso-the-rust-foundations-new-director-of-outreach/">Director of Outreach</a> my job is twofold: providing both <em>inreach</em> into the Project and <em>outreach</em> to the larger tech community and users of Rust. As part of my inreach function I have the privilege to work with members of the Rust Project, sitting in on a variety of meetings to find the Project's needs and find opportunities for the Foundation to solve problems. I am working with the Project Directors and the Leadership Council as a liaison to the Foundation and as a resource for attracting funds for the Project to allocate via the Project Priorities Budget, and I will be working with Project leadership to retool the Project Grant Program so it can better serve the Project.</p> <p>Along similar lines is the <em>outreach</em> component of my role — to work with the broader tech community to bring them to our table. Several popular open source projects have key parts built in Rust, including <a href="https://valkey.io/">Valkey</a>, <a href="https://bootc-dev.github.io/">bootc</a>, <a href="https://linkerd.io/">Linkerd</a>, and <a href="https://openebs.io/">OpenEBS</a> — which are all part of the Cloud Native Computing Foundation (CNCF) housed at the Linux Foundation. These projects use Rust but may or may not have formal ties to the Project itself or to the Foundation. My goal is to go outside and find more projects like these and introduce them to people here so they can share their experiences coding in Rust and create not only a feedback loop as end users but build a relationship with the Project — potentially becoming members themselves of the Project and the Foundation. The more we can share how Rust is being used, and make the resources available to support that use, the better.</p> <p>In fact, the Project has long done this kind of work, e.g. with its deep and productive collaborations with <a href="https://rust-for-linux.com/">Rust for Linux</a> and <a href="https://bevy.org/">Bevy</a>. I'm excited to "stand on the shoulders of giants" and to build on these successes.</p> <p>All of this sounds great but how does it relate to "crossing the streams?" I'm excited to say that I have in fact crossed the streams and am now a member of the Rust Project's newly formed <a href="https://www.rust-lang.org/governance/teams/launching-pad#team-content">Content Team</a>. That in turn has made me a member of the Rust Project itself! I'm grateful to TC and Pete LeVasseur for imagining this team, making it a reality, and then welcoming me on board. Our first journey into content creation is at RustConf where we are sitting down and interviewing people within the Project and our ecosystem to post on the <a href="https://blog.rust-lang.org/">Rust blog</a>, YouTube, and other online venues. You can find the team's charter and read more about our goals <a href="https://github.com/rust-lang/leadership-council/issues/206">here</a>.</p> <p>Being a part of this team was the icing on the cake for me. Being a member of the Content Team gives me the opportunity to contribute directly to the work of the Project while having "insider access" to the Project's ecosystem. We get to share not only "how the sausage is made", but we get to tell the stories of maintainers, contributors, and end users while showcasing how the work being done in the Project affects the future of the language and its widespread adoption across many industries.</p> <p>The TL;DR (too late) is that by crossing the streams between my job at the Foundation and my volunteer work with the Rust Project Content Team I am hoping that we are setting ourselves up for success. To me success looks like developing a clearer understanding of the Foundation's role in supporting the Project, improving communication between the Project and the Foundation as we work together to generate and execute on solutions to obstacles facing the Project, and telling the stories of end users and other projects that are using Rust to advance the open source economy and ecosystem.</p> <p>If you want to chat you can find me on Zulip!</p> Lori Lorusso 2025-08-26T00:00:00+00:00 2025-08-26T00:00:00+00:00 https://blog.rust-lang.org/inside-rust/2025/08/26/removing-inactive-members-from-github-organizations/ <p>The Infrastructure Team is cleaning up GitHub organizations managed by the Rust Project (<a href="https://github.com/rust-lang">rust-lang</a>, <a href="https://github.com/rust-dev-tools">rust-dev-tools</a>, <a href="https://github.com/rust-lang-deprecated">rust-lang-deprecated</a>, <a href="https://github.com/rust-lang-nursery">rust-lang-nursery</a> and <a href="https://github.com/rust-analyzer">rust-analyzer</a>) by removing members who are not part of any team within those organizations.</p> <p>If you are currently a member of one of these GitHub organizations, you might receive a removal email from GitHub that notifies you that you have been removed from some of them. If you are currently an active Rust team member, then do not worry! Your access to the <code>rust-lang</code> organization won't be affected by this, and at most we will remove you from some of the legacy organizations that are no longer in active use.</p> <p>If you contributed to Rust in the past and you are no longer an active contributor, then we will likely remove you from all of the mentioned GitHub organizations. We understand that some people publicly displayed their membership in the <code>rust-lang</code> organization as a recognition of past contributions. As an alternative, your contributor status is shown on the official <a href="https://www.rust-lang.org/governance#teams">teams page</a> of the Rust website, which includes an alumni section for each team. Please reach out if your past team memberships are not reflected on this page. Also, we want to take this opportunity to thank you for the time you spent in the past making Rust what it is today!</p> <p>If you have been removed from an organization you think you should be part of, or you have any other questions, please reach out on our chat platform, <a href="https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/removing.20inactive.20members.20from.20the.20org">Zulip</a>.</p> <h2 id="archived-teams"><a class="anchor" href="#archived-teams" aria-hidden="true"></a> Archived teams</h2> <p>Unfortunately, archived teams are not shown on the website's governance page, so previous Rust Project members who were part of archived teams only won't be listed in any alumni section.</p> <p>We created a <a href="https://github.com/rust-lang/www.rust-lang.org/issues/2181">GitHub issue</a> to track this, but in the meantime we would like to thank these contributors in this post:</p> <ul> <li><a href="https://github.com/alexheretic">alexheretic</a></li> <li><a href="https://github.com/am-1t">am-1t</a></li> <li><a href="https://github.com/arora-aman">arora-aman</a></li> <li><a href="https://github.com/autozimu">autozimu</a></li> <li><a href="https://github.com/avadacatavra">avadacatavra</a></li> <li><a href="https://github.com/azhng">azhng</a></li> <li><a href="https://github.com/azuremarker">azuremarker</a></li> <li><a href="https://github.com/basil-cow">basil-cow</a></li> <li><a href="https://github.com/bawerd">bawerd</a></li> <li><a href="https://github.com/benlewis-seequent">benlewis-seequent</a></li> <li><a href="https://github.com/chrispardy">chrispardy</a></li> <li><a href="https://github.com/comex">comex</a></li> <li><a href="https://github.com/detrumi">detrumi</a></li> <li><a href="https://github.com/djcarpe">djcarpe</a></li> <li><a href="https://github.com/gnunicorn">gnunicorn</a></li> <li><a href="https://github.com/hameerabbasi">hameerabbasi</a></li> <li><a href="https://github.com/hdhoang">hdhoang</a></li> <li><a href="https://github.com/hkmatsumoto">hkmatsumoto</a></li> <li><a href="https://github.com/inquisitivecrystal">inquisitivecrystal</a></li> <li><a href="https://github.com/jamespatrickgill">jamespatrickgill</a></li> <li><a href="https://github.com/jasonwilliams">jasonwilliams</a></li> <li><a href="https://github.com/jduchniewicz">jduchniewicz</a></li> <li><a href="https://github.com/jechasteen">jechasteen</a></li> <li><a href="https://github.com/jenniferwills">jenniferwills</a></li> <li><a href="https://github.com/logmosier">logmosier</a></li> <li><a href="https://github.com/lucasbullen">lucasbullen</a></li> <li><a href="https://github.com/markmccaskey">markmccaskey</a></li> <li><a href="https://github.com/mstallmo">mstallmo</a></li> <li><a href="https://github.com/mystor">mystor</a></li> <li><a href="https://github.com/nagashi">nagashi</a></li> <li><a href="https://github.com/nathanwhit">nathanwhit</a></li> <li><a href="https://github.com/null-sleep">null-sleep</a></li> <li><a href="https://github.com/o0ignition0o">o0ignition0o</a></li> <li><a href="https://github.com/pcwalton">pcwalton</a></li> <li><a href="https://github.com/peschkaj">peschkaj</a></li> <li><a href="https://github.com/qmx">qmx</a></li> <li><a href="https://github.com/roxelo">roxelo</a></li> <li><a href="https://github.com/seanchen1991">seanchen1991</a></li> <li><a href="https://github.com/stupremee">stupremee</a></li> <li><a href="https://github.com/tamuhey">tamuhey</a></li> <li><a href="https://github.com/valgrimm">valgrimm</a></li> <li><a href="https://github.com/vlad20012">vlad20012</a></li> <li><a href="https://github.com/whitequark">whitequark</a></li> <li><a href="https://github.com/zaharidichev">zaharidichev</a></li> </ul> <h2 id="hidden-teams"><a class="anchor" href="#hidden-teams" aria-hidden="true"></a> Hidden teams</h2> <p>Some Rust teams, such as marker teams and some working groups are not shown in the website's governance page.</p> <p>We would like to thank the contributors who only belong to these teams in this post:</p> <ul> <li><a href="https://github.com/adamgreig">adamgreig</a></li> <li><a href="https://github.com/AlexEne">AlexEne</a></li> <li><a href="https://github.com/andre-richter">andre-richter</a></li> <li><a href="https://github.com/AngelOnFira">AngelOnFira</a></li> <li><a href="https://github.com/Dajamante">Dajamante</a></li> <li><a href="https://github.com/eldruin">eldruin</a></li> <li><a href="https://github.com/hargoniX">hargoniX</a></li> <li><a href="https://github.com/korken89">korken89</a></li> <li><a href="https://github.com/kvark">kvark</a></li> <li><a href="https://github.com/levex">levex</a></li> <li><a href="https://github.com/luqmana">luqmana</a></li> <li><a href="https://github.com/Nashenas88">Nashenas88</a></li> <li><a href="https://github.com/retep998">retep998</a></li> <li><a href="https://github.com/ryankurte">ryankurte</a></li> <li><a href="https://github.com/thejpster">thejpster</a></li> <li><a href="https://github.com/therealprof">therealprof</a></li> <li><a href="https://github.com/tromey">tromey</a></li> </ul> <h2 id="members-without-contact"><a class="anchor" href="#members-without-contact" aria-hidden="true"></a> Members without contact</h2> <p>Some past members are not listed in the <a href="https://github.com/rust-lang/team">rust-lang/team</a> repo, so we are unable to add them to the alumni sections and list them in the website.</p> <p>If you are one of these members and want to be listed in the alumni sections of your previous teams, please open a PR in the <a href="https://github.com/rust-lang/team">rust-lang/team</a> repo.</p> <p>We would like to thank these contributors in this post:</p> <ul> <li><a href="https://github.com/aajtodd">aajtodd</a></li> <li><a href="https://github.com/aatxe">aatxe</a></li> <li><a href="https://github.com/adrq">adrq</a></li> <li><a href="https://github.com/ALCC01">ALCC01</a></li> <li><a href="https://github.com/alecmocatta">alecmocatta</a></li> <li><a href="https://github.com/andrewtj">andrewtj</a></li> <li><a href="https://github.com/anp">anp</a></li> <li><a href="https://github.com/anxiousmodernman">anxiousmodernman</a></li> <li><a href="https://github.com/aravind-pg">aravind-pg</a></li> <li><a href="https://github.com/arazabishov">arazabishov</a></li> <li><a href="https://github.com/ashfordneil">ashfordneil</a></li> <li><a href="https://github.com/autodidaddict">autodidaddict</a></li> <li><a href="https://github.com/azdle">azdle</a></li> <li><a href="https://github.com/blitzerr">blitzerr</a></li> <li><a href="https://github.com/bluss">bluss</a></li> <li><a href="https://github.com/brendanzab">brendanzab</a></li> <li><a href="https://github.com/cassiersg">cassiersg</a></li> <li><a href="https://github.com/championshuttler">championshuttler</a></li> <li><a href="https://github.com/chrisvittal">chrisvittal</a></li> <li><a href="https://github.com/CryZe">CryZe</a></li> <li><a href="https://github.com/dhuseby">dhuseby</a></li> <li><a href="https://github.com/dibsonmuad">dibsonmuad</a></li> <li><a href="https://github.com/Diggsey">Diggsey</a></li> <li><a href="https://github.com/dirtybit">dirtybit</a></li> <li><a href="https://github.com/dustypomerleau">dustypomerleau</a></li> <li><a href="https://github.com/dyxushuai">dyxushuai</a></li> <li><a href="https://github.com/ehsanmok">ehsanmok</a></li> <li><a href="https://github.com/ELD">ELD</a></li> <li><a href="https://github.com/emberian">emberian</a></li> <li><a href="https://github.com/ereichert">ereichert</a></li> <li><a href="https://github.com/fairingrey">fairingrey</a></li> <li><a href="https://github.com/flaper87">flaper87</a></li> <li><a href="https://github.com/fmckeogh">fmckeogh</a></li> <li><a href="https://github.com/gaurikholkar-zz">gaurikholkar-zz</a></li> <li><a href="https://github.com/gavento">gavento</a></li> <li><a href="https://github.com/GeertVL-zz">GeertVL-zz</a></li> <li><a href="https://github.com/gereeter">gereeter</a></li> <li><a href="https://github.com/giannicic">giannicic</a></li> <li><a href="https://github.com/glandium">glandium</a></li> <li><a href="https://github.com/gruberb">gruberb</a></li> <li><a href="https://github.com/gsollazzo">gsollazzo</a></li> <li><a href="https://github.com/h1467792822">h1467792822</a></li> <li><a href="https://github.com/Haggus">Haggus</a></li> <li><a href="https://github.com/hrvolapeter">hrvolapeter</a></li> <li><a href="https://github.com/ibabushkin">ibabushkin</a></li> <li><a href="https://github.com/inejge">inejge</a></li> <li><a href="https://github.com/jbcden">jbcden</a></li> <li><a href="https://github.com/jdm">jdm</a></li> <li><a href="https://github.com/jethrogb">jethrogb</a></li> <li><a href="https://github.com/jkelleyrtp">jkelleyrtp</a></li> <li><a href="https://github.com/jkordish">jkordish</a></li> <li><a href="https://github.com/jkozlowski">jkozlowski</a></li> <li><a href="https://github.com/JoeyEremondi">JoeyEremondi</a></li> <li><a href="https://github.com/JoshMcguigan">JoshMcguigan</a></li> <li><a href="https://github.com/jroesch">jroesch</a></li> <li><a href="https://github.com/jrozner">jrozner</a></li> <li><a href="https://github.com/JuanPotato">JuanPotato</a></li> <li><a href="https://github.com/justahero">justahero</a></li> <li><a href="https://github.com/khaledkbadr">khaledkbadr</a></li> <li><a href="https://github.com/KiChjang">KiChjang</a></li> <li><a href="https://github.com/kiljacken">kiljacken</a></li> <li><a href="https://github.com/kjeremy">kjeremy</a></li> <li><a href="https://github.com/kleimkuhler">kleimkuhler</a></li> <li><a href="https://github.com/koute">koute</a></li> <li><a href="https://github.com/kulshrax">kulshrax</a></li> <li><a href="https://github.com/kupiakos">kupiakos</a></li> <li><a href="https://github.com/leoyvens">leoyvens</a></li> <li><a href="https://github.com/lf">lf</a></li> <li><a href="https://github.com/lilyball">lilyball</a></li> <li><a href="https://github.com/listochkin">listochkin</a></li> <li><a href="https://github.com/lloydmeta">lloydmeta</a></li> <li><a href="https://github.com/Lubits">Lubits</a></li> <li><a href="https://github.com/marcusklaas">marcusklaas</a></li> <li><a href="https://github.com/memoryruins">memoryruins</a></li> <li><a href="https://github.com/Michael-F-Bryan">Michael-F-Bryan</a></li> <li><a href="https://github.com/mikhail-m1">mikhail-m1</a></li> <li><a href="https://github.com/mitsuhiko">mitsuhiko</a></li> <li><a href="https://github.com/nbp">nbp</a></li> <li><a href="https://github.com/NikVolf">NikVolf</a></li> <li><a href="https://github.com/nox">nox</a></li> <li><a href="https://github.com/orenwf">orenwf</a></li> <li><a href="https://github.com/orium">orium</a></li> <li><a href="https://github.com/pambihira">pambihira</a></li> <li><a href="https://github.com/pepyakin">pepyakin</a></li> <li><a href="https://github.com/PramodBisht">PramodBisht</a></li> <li><a href="https://github.com/rholderfield">rholderfield</a></li> <li><a href="https://github.com/ritiek">ritiek</a></li> <li><a href="https://github.com/rolftimmermans">rolftimmermans</a></li> <li><a href="https://github.com/sanxiyn">sanxiyn</a></li> <li><a href="https://github.com/sapphire-arches">sapphire-arches</a></li> <li><a href="https://github.com/soniasingla">soniasingla</a></li> <li><a href="https://github.com/stokhos">stokhos</a></li> <li><a href="https://github.com/strega-nil">strega-nil</a></li> <li><a href="https://github.com/sunjay">sunjay</a></li> <li><a href="https://github.com/tinaun">tinaun</a></li> <li><a href="https://github.com/tomaka">tomaka</a></li> <li><a href="https://github.com/totsteps">totsteps</a></li> <li><a href="https://github.com/treiff">treiff</a></li> <li><a href="https://github.com/tynril">tynril</a></li> <li><a href="https://github.com/uberjay">uberjay</a></li> <li><a href="https://github.com/vadimcn">vadimcn</a></li> <li><a href="https://github.com/Veetaha">Veetaha</a></li> <li><a href="https://github.com/wain303009">wain303009</a></li> <li><a href="https://github.com/wirelessringo">wirelessringo</a></li> <li><a href="https://github.com/xmonader">xmonader</a></li> <li><a href="https://github.com/Xylakant">Xylakant</a></li> <li><a href="https://github.com/Yarn">Yarn</a></li> </ul> Marco Ieni 2025-08-20T00:00:00+00:00 2025-08-20T00:00:00+00:00 https://blog.rust-lang.org/inside-rust/2025/08/20/electing-new-project-directors-2025/ <p>Today we are launching the process to elect three Project Directors to the Rust Foundation Board of Directors. This is the second round of slots, following from <a href="https://blog.rust-lang.org/inside-rust/2024/09/06/electing-new-project-directors/">last year's election</a>.</p> <p>We will briefly explain the goals and procedures here, but this is mostly copy-pasted from <a href="https://blog.rust-lang.org/inside-rust/2024/09/06/electing-new-project-directors/">last year's post</a> and the <a href="https://github.com/rust-lang/leadership-council/blob/main/policies/project-directorship/election-process.md">official process documentation</a>.</p> <p>We ask all Project members to begin working with their Leadership Council representative to nominate potential Project Directors. See the <a href="https://blog.rust-lang.org/inside-rust/2025/08/20/electing-new-project-directors-2025/#candidate-gathering">candidate gathering</a> section for more details. Nominations are due by September 18, 2025.</p> <h2 id="what-are-project-directors"><a class="anchor" href="#what-are-project-directors" aria-hidden="true"></a> What are Project Directors?</h2> <p>The Rust Foundation Board of Directors has five seats reserved for Project Directors. These Project Directors serve as representatives of the Rust Project itself on the Board. Like all directors on the Foundation board, the Project Directors are elected by the entity they represent, which in the case of the Rust Project means they are elected by the Rust Leadership Council. Project Directors serve for a term of two years and will have staggered terms. This year we will appoint three directors and next year we will appoint two directors.</p> <p>See the <a href="https://github.com/rust-lang/leadership-council/blob/main/roles/rust-foundation-project-director.md">role description</a> document for more details about what is involved in being a Project Director.</p> <p>The current Project Directors are Carol Nichols, Ryan Levick, Santiago Pastorino, Scott McMurray, and Jakob Degen. This year, Santiago Pastorino, Scott McMurray, and Jakob Degen's seats are open for election.</p> <p>We want to make sure the Project Directors can effectively represent the Project as a whole, so we are soliciting input from everyone on the team. The elections process will go through two phases: 1) candidate gathering and 2) election. Read on for more detail about how these work.</p> <h2 id="candidate-gathering"><a class="anchor" href="#candidate-gathering" aria-hidden="true"></a> Candidate gathering</h2> <p>The first phase is beginning right now. In this phase, we are inviting the members of all of the top level Rust teams and their subteams to nominate people who would make good Project Directors. The goal is to bubble these up to the Council through each of the top-level teams. You should be hearing from your Council representative soon with more details, but if not, feel free to reach out to that person directly.</p> <p>Each team is encouraged to suggest candidates. Since we are electing three directors, it would be ideal for teams to nominate at least two candidates. Nominees can be anyone in the Project and do not have to be a member of the team who nominates them.</p> <p>The candidate gathering process will be open until September 18, at which point each team's Council representative will share that team's nominations and reasoning with the whole Leadership Council. At this point, the Council will confirm with the nominees that they are willing to accept the nomination and fill the role of Project Director if selected. Then the Council will publish the set of candidates.</p> <p>This then starts a period where members of the Rust Project are invited to share feedback on the nominees with the Council. This feedback can include reasons why a nominee would make a good Project Director or concerns the Council should be aware of.</p> <p>The Council will announce the set of nominees by September 19 and the feedback period will last until October 2. Once this time has passed, we will move on to the election phase.</p> <h2 id="election"><a class="anchor" href="#election" aria-hidden="true"></a> Election</h2> <p>The Council will meet on October 3 to complete the election process. In this meeting we will discuss each candidate and once we have done this the facilitator will propose a set of three to be the new Project Directors. The facilitator puts this to a vote, and if the Council unanimously agrees with the proposed set of candidates then the process is complete. Otherwise, we will give another opportunity for council members to express their objections and we will continue with another proposal. This process repeats until we find a set of nominees to whom the Council can unanimously consent. The Council will then confirm these nominees through an official vote delivered to the Foundation.</p> <p>Once this is done, we will announce the new Project Directors. In addition, we will contact each of the nominees, including those who were not elected, to offer feedback. For those who accept feedback we will follow up to tell them a little bit more about what we saw as their strengths and opportunities for growth to help them serve better in similar roles in the future.</p> <h2 id="timeline"><a class="anchor" href="#timeline" aria-hidden="true"></a> Timeline</h2> <p>This process will continue through all of September and into October. Below are the key dates:</p> <ul> <li>Candidate nominations due: September 18</li> <li>Candidates published: September 19</li> <li>Feedback period: September 19 - October 2</li> <li>Election meeting: October 3</li> <li>First board meeting starting the new term: October 14</li> </ul> <p>After the election meeting happens, the Rust Leadership Council will announce the results and the new Project Directors will assume their responsibilities.</p> <h2 id="acknowledgments"><a class="anchor" href="#acknowledgments" aria-hidden="true"></a> Acknowledgments</h2> <p>A number of people have been involved in designing and launching this election process and we wish to extend a heartfelt thanks to all of them!</p> <p>We'd especially like to thank Eric Holk, Ryan Levick, and TC for helping to improve our process.</p> Tomas Sedovic 2025-08-15T00:00:00+00:00 2025-08-15T00:00:00+00:00 https://blog.rust-lang.org/inside-rust/2025/08/15/leadership-council-repr-selection/ <p>The selection process for representatives on the <a href="https://www.rust-lang.org/governance/teams/leadership-council">Leadership Council</a> is starting today.</p> <p>Every six months, half of the council terms end. The following teams are up to choose their representative for the next year:</p> <ul> <li><a href="https://www.rust-lang.org/governance/teams/infra">Infra</a></li> <li><a href="https://www.rust-lang.org/governance/teams/lang">Lang</a></li> <li><a href="https://www.rust-lang.org/governance/teams/library">Libs</a></li> <li><a href="https://www.rust-lang.org/governance/teams/moderation">Mods</a></li> </ul> <p>We are aiming to have the teams confirm their choices by September 19, 2025, and for any possible new members to be ready to join the council meetings starting September 26th.</p> <h2 id="criteria-for-representatives"><a class="anchor" href="#criteria-for-representatives" aria-hidden="true"></a> Criteria for representatives</h2> <p>Any member of the top-level team or a member of any of their subteams is eligible to be the representative. See <a href="https://forge.rust-lang.org/governance/council.html#candidate-criteria">candidate criteria</a> for a description of what makes a good representative.</p> <p>There is a limit of at most two people affiliated with the same company or other legal entity being on the council <sup class="footnote-reference" id="fr-affiliates-1"><a href="#fn-affiliates">1</a></sup>. During the selection process, the council will consider the affiliation of candidates to decide if all choices will be compatible with that constraint.</p> <p>Representatives may serve multiple terms if the team decides to choose the same representative again. There is a soft limit of three terms.<sup class="footnote-reference" id="fr-limit-1"><a href="#fn-limit">2</a></sup> It is recommended that teams rotate their representatives if possible to help avoid burnout and to spread the experience to a broader group of people.</p> <h2 id="what-do-representatives-do"><a class="anchor" href="#what-do-representatives-do" aria-hidden="true"></a> What do Representatives do?</h2> <p>A representative provides a voice on the council to represent the interests of their teams and contribute to the long-term success of the Rust Project. A detailed description of the role may be found at the <a href="https://github.com/rust-lang/leadership-council/blob/main/roles/council-representative.md">Representative Role Description</a>.</p> <h2 id="how-should-teams-make-their-selection"><a class="anchor" href="#how-should-teams-make-their-selection" aria-hidden="true"></a> How should teams make their selection?</h2> <p>The Leadership Council has put together a <a href="https://github.com/rust-lang/leadership-council/blob/main/guides/representative-selection.md">Representative Selection Guide</a> with recommendations for teams on how to go about choosing a representative. It is not a requirement that teams follow this guide; top-level teams may choose their own process.</p> <section class="footnotes"> <ol class="footnotes-list"> <li id="fn-affiliates"> <p>See <a href="https://forge.rust-lang.org/governance/council.html#limits-on-representatives-from-a-single-companyentity">Limits on representatives from a single company/entity</a> <a href="#fr-affiliates-1">↩</a></p> </li> <li id="fn-limit"> <p>See <a href="https://forge.rust-lang.org/governance/council.html#term-limits">Term limits</a>. <a href="#fr-limit-1">↩</a></p> </li> </ol> </section> Eric Huss