@epage@hachyderm.io

Ed Page @epage@hachyderm.io

· 5mo ago

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

doc.rust-lang.org

44

2

16

1

Ed Page @epage@hachyderm.io

· 6mo ago

Replying to

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

github.com

25

1

6

1

Ed Page @epage@hachyderm.io

· 3mo ago

Replying to

@rkaj@mastodon.nu @chaotic_neutral_dev@tech.lgbt Agreed about no standard. There are clippy lints to at least force one or the other in your own project.

I prefer foo/mod.rs

keeps the mod all together (one thing to move, grep, etc)
foo.rs is a signal to me that I'm looking at a leaf mod and it is confusing when that isn't true

4

1

0

Ed Page @epage@hachyderm.io

· 6mo ago

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

blog.rust-lang.org

16

0

14

1

Ed Page @epage@hachyderm.io

· 6mo ago

Replying to

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

9

2

1

0

Ed Page @epage@hachyderm.io

· 5mo ago

Replying to

@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.

3

0

Ed Page @epage@hachyderm.io

· 9mo ago

Replying to

@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.

7

10

0

Ed Page @epage@hachyderm.io

· 6mo ago

Replying to

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

epage.github.io

Guideline: PR Style

3

0

1

0

Ed Page @epage@hachyderm.io

· 6mo ago

Replying to

@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.

epage.github.io

1

5

0

Ed Page @epage@hachyderm.io

· 9mo ago

Replying to

@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.

1

0

Ed Page @epage@hachyderm.io

· 6mo ago

Replying to

@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.

0

1

0

Ed Page @epage@hachyderm.io

· 6mo ago

Replying to

@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.

epage.github.io

0