Ed Page

@argv_minus_one@mastodon.sdf.org One approach would be a cross crate used/unused pub item tracking with what cfgs the item has. Cargo could then report if all pub items for a feature are unused. This would only have false positives for features that are both behavior changes and API additions. This would also be useful for workspace-private crates for detecting unused code. I'm assuming this would be expensive to track, including the serializing and deserializing of intermediate state between rustc and cargo.

Cargo now has unstable support for detecting unused dependencies. For its most basic form, you can run:

```
cargo +nightly check -Zcargo-lints --workspace --all-targets
```

See https://doc.rust-lang.org/nightly/cargo/guide/build-performance.html#removing-unused-dependencies for more details

#rustlang

I'm now following that up with one for contributing to projects: https://epage.github.io/dev/pr-style/

Apparently, this is also being discussed at https://lobste.rs/s/msgigh/guideline_rust_style

@diondokter This is for a very particular case: you have a public type that is purely a newtype for a data-only inner type. In particular for enums, this is a technique to make your variants private. This is similar to what you said about sometimes you need the contexts of a private items to understand public items. BarInner exists purely for Bar and is that kind of context. Think of struct Bar and enum BarInner as one unit.

@diondokter

https://epage.github.io/dev/rust-style/#m-pub-priv I generally agree with it. But it is possible for a private type to be more relevant to user understanding than another public type and thus warrants being put above it.

Note that M-CALLER-CALLEE goes before it and calls out: "The weaker the abstraction of the callee, the more immediately after the caller it should be."

I assume that covers your situation?

https://epage.github.io/dev/rust-style/#m-assoc-trait Sometimes a trait impl is more important than seeing the functions. Probably not true for normal trait impls like Clone or Display. Definitely put those last yeah

That guideline provides some important context for it: "Typically, associated functions form the core API for a type and trait implementations augment that API."

Sounds like you are dealing with exception cases. That said, I can only think of a couple of places where I intentionally do not follow this guideline.

@diondokter

Some of the item ordering stuff seems a little too strict to me and I have slight disagreements.

The ordering rules can't be implemented strictly because they are self-contradictory leading to https://epage.github.io/dev/rust-style/#m-ambiguity

I'd be curious to know where you disagree and why you find that ordering helpful.

I've been organizing my lessons learned in writing readable code as a Rust Style Guide: https://epage.github.io/dev/rust-style/

This is more for organizing my thoughts and maybe having to reference back to when discussing how to improve the readability of code and not something where every items needs to be strictly enforced. I also suspect I could put more time into the motivations for some of the items. Even then, I expect not everyone will agree with every point.

Any principles or practices you've found that makes code more readable that I might have overlooked?

#rustlang

Cargo Call for Testing: the build-dir is changing and we need help with people testing it for issues, particularly in identifying tools and processes that rely on unspecified implementation details of Cargo.

See https://blog.rust-lang.org/2026/03/13/call-for-testing-build-dir-layout-v2/

#rustlang

Unfortunately, there are many things left to do, including

• Improving the supply chain management story for Cargo including for MSRV, minimum-release-age, rustsec integration, auditing, etc
• More Cargo build performance improvements
• Improve the performance and experience in writing Rust tests and iterating on failures
• Finish design and implementation on Cargo plumbing commands
• Finish implementation for new cargo fix architecture

Off the top of my head, some accomplishments from along the way:

• Getting clap v3 out (stuck in limbo for years) and then v4
• Polish on and continued maintenance of typos
• Creation of trycmd to test clap's documentation
• Making winnow
• Making toml_edit production ready
• Getting cargo add into Cargo
• Mentored the work on Cargo's workspace inheritance
• 2 rewrites of toml
• Creation of anstyle and anstream, providing an alternative approach to enriching CLIs
• Significant work to cargo release
• Keeping the lights on for many crates at https://github.com/rust-cli/
• Cargo script, from experiments to it being approved for stabilization (stabilization is pending)
• Designed and implemented [lints] support in Cargo, an idea people had given up on (which I didn't know at the time)
• MSRV-aware dependency resolver for Cargo (originally thought impossible with the current code base)
• Created a vision and roadmap for improving the test experience for Cargo users
• Pulling snapbox out of trycmd and making it scale to Cargo's needs
• Mentored work on Cargo workspace publishing
• Led exploration in defining plumbing commands for Cargo
• Led exploration in alternative architectures for cargo fix to better scale with large workspaces
• Advocated for a cross-project, user-centric perspective on build performance
• Performance optimizations in Cargo
• Spoke at RustNL, GOSIM, Rust in Paris, and RustWeek

My job role has changed, making me no longer sponsored full time for undirected Rust development. Almost 5 years is a good run and I appreciate what my company has allowed me to do in that time and for still providing me a role at the conclusion of that run.

I will be needing to scale back my role on the Cargo team and the maintenance of my crates. What this will look like exactly? I'm not sure yet. Obvious answers are that I will no longer be writing the This Development in Cargo blog series and giving micro-reports here on where my time is going.

Something that will help is that a focus of mine for Cargo and my crates was to streamline maintenance.

Notification backlog progress:
- Day start: 87
- Day end: 79

Additional accomplishments:
- https://github.com/Embers-of-the-Fire/cargo-dlx/pull/13
- https://github.com/Embers-of-the-Fire/cargo-dlx/pull/14
- https://github.com/assert-rs/assert_cmd/pull/281
- https://github.com/assert-rs/assert_cmd/pull/282
- https://github.com/assert-rs/snapbox/pull/431

Notification backlog progress:
- Day start: 89
- Day end: 87

Additional accomplishments:
- https://github.com/winnow-rs/winnow/pull/876
- https://github.com/winnow-rs/winnow/pull/878
- https://github.com/winnow-rs/winnow/pull/879
- https://github.com/winnow-rs/winnow/pull/880

Notification backlog progress:
- Day start: 95
- Day end: 80

Additional accomplishments:
- https://github.com/rust-lang/cargo/pull/16700
- https://github.com/toml-rs/toml/pull/1116
- https://github.com/rust-lang/cargo/pull/16702

@KFears@mstdn.games @vavakado@mas.to Maybe. We can't know what would have happened and that is disappointing. And to be clear, the harm to that person is the greatest disappointment. From my understanding of the chain of events, I have a hard time saying what more or less should have been done. Several people are no longer in the roles they were in that were related to critical failures in the process. One of those people is still involved with the project and I see them to today living up to their promised actions.

@vavakado@mas.to @KFears@mstdn.games this is referring to a situation a couple years ago where a chain of actions from several well intentioned people caused a keynote for RustConf to be canceled which was kicked off by dtolnay which people quickly assumed was driven by racism before the facts were known which was compounded by at least one well known Rust community member (but outside the project) making a racist comment that the speaker was only chosen for diversity (they were not). The weight of blame put on dtolnay was made worse by them taking limited responsibility for their part including delaying an apology until they were outed and then doing a poor one. It also has not killed off comptime reflection, just that approach from that contributor. There is on going work in that area by a compiler team member that I am much more hopeful about the design of. This isn't that I'm a dtolnay apologist. Its just that to work to solve problems you need to make sure you know what the problems are.