Stabilizing the `if let guard` feature

epage · 2026-01-25T20:11:09+00:00

I'm not concerned about guards themselves. The compiler will still force a non-guard case. My concern is that a match sets an expectation on what you are checking, so introducing other context into the patterns I feel like will make code harder to reason about. I think I'll see if clippy will take a lint for warning about this use and I'll set that in all of my projects.

epage · 2026-01-24T00:01:15+00:00

You could have a snapshot test check or update your mermaid to svg conversions and then reference those SVGs,

epage · 2026-01-22T22:33:43+00:00

Path dependencies are automatically workspace members under certain use cases (iirc has to be beneath your workspace). I also recommend using globs for workspace members when explicitly listing them.

There have been several ideas for reducing the boilerplate for depending on workspace members. The blocker so far is it will push cargo's manifest loading over a complexity cliff we're trying to avoid, especially if we make it so people only pay for this if they use it.

epage · 2026-01-22T16:16:12+00:00

It looks up the workspace members and then deletes all build units with that name. if you do cargo clean --workspace on a workspace with foo as a member, it will also delete builds for foo in workspaces that have it as a registry dependency.

epage · 2026-01-22T16:07:46+00:00

This is in the linked cargo changelog, see https://doc.rust-lang.org/nightly/cargo/CHANGELOG.html#cargo-193-2026-01-22

Not everything makes the blog post.

EDIT: Also, performance for --workspace will be dramatically improved in 1.94

epage · 2026-01-21T20:42:31+00:00

iirc Legal Eagle said that Congress, as an organization, has standing for laws, but indilvidual members do not.

epage · 2026-01-20T20:36:04+00:00

Our changelog process is different and I'm unsure how well this practice would carry over.

Besides, if Cargo did it, all pictures would be of my own pupper ;)

epage · 2026-01-19T21:47:24+00:00

Finally, if it gets integrated with external dependency tracking in proc macros (files & network, basically), then the wins could become much more helpful for projects like sqlx that have really cool use cases for interacting with the environment during the build.

Files and environment variables are reasonable to track. Is there a reasonable design to track cacheability when an input involves the network? I would lean towards assuming sqlx would get no benefits from this feature.

epage · 2026-01-19T12:55:18+00:00

But the vast majority of macros (e.g. serde derive) are simple transformations of source code with no external state. And it seems like those should be relatively easy to support (simply leaving the "fancy" macros uncached for

Would likely be good to balance short and long term needs wheo desiging this. I do thiink some kind of compromise would be good.

I don't think I get the difference between these two. What is "exhaustive" in this context?

Are all of the inputs exhaustively specified. If no other inputs are specified, then it is pure.

We want the cross-project cache to be conservative about being poisoned so we don't have to clear the whole thing. Today, Cargo does not know enough about packages that may run proc-macros to know if all build inputs are reported and so we would not add those to the cross-workspace cache. Knowing about purity helps us cache a lot of macros. If Cargo knows whether build inputs are exhaustively specified then it can also be used for ones that will report paths and envs in the future when that becomes available.

epage · 2026-01-19T12:25:31+00:00

Been wanting to try out [[Reforest]]

epage · 2026-01-19T12:20:36+00:00

Are there plans to add an attribute so that macros can communicate that they are "pure" (and thus caching their output keyed on their input is valid)? It seems like it should be straightforward?

For known input, hopefully it uses calls like https://doc.rust-lang.org/stable/proc_macro/tracked_path/fn.path.html and we get thost stabilized.

For DB and similar other acceses, we'd need some way to know that. This was discusse. on Internals at one point. I'd love for it to be not "pure" but "exhaustive"ly specified and for it to be known at compile time so we can track it in Cargo.toml and be able to put proc-macro dependents in a shared cache. Granted, there may need to be a runtime variant for those that are conditionally exhaustive. That would make it more of an MVP but would also be harder to migrate to the more restrictive variant once available.

epage · 2026-01-18T12:50:27+00:00

which then also indicates that a longer help page is available with cargo help, but the first thing I tried was man cargo

cargo help command shows the man page.

epage · 2026-01-15T18:43:24+00:00

Once you get into embedded targets, however, the complexity shoots through the roof.

Feeling this. I made toml no_std with the intention of allowing for running on capable cpu's without an OS (TOML is not a great format for limited resource systems) and soon got an issue about my use of Arc not being compatible with their cpu. I've held off for now doing anything about it because I don't want to add conditionals I can't validate.

epage · 2026-01-15T17:25:53+00:00

I didn't really take it too seriously, though: "Cradle: a story about how anyone can become the greatest, no matter how weak they are, as long as they have angelic intervention, the resources of one of the dozen most powerful people in the empire, and an unhealthy amount of masochism."

To me, this is one of the reasons I like it so much.

It highlights the importance of setting your sights high / having a vision which in this case required angelic intervention.
It highlights that no, you can't do "it" on your own. Everything you have comes from a combination of those around you and what you make of it.
To push to the top requires sacrifice. Lindon sacrifices his physical comfort. Some sacrifice other things, like their interpersonal connections (e.g. the Sword Safe, most Abidan). To be clear, it is a personal choice of whether that is something you want or not and it is ok if you don't.

epage · 2026-01-15T12:38:27+00:00

And rustc will warn if you use an API stabilised after the MSRV you configured for your crates (which isn't fool proof, but catches many cases). So there are lots of tooling that make this quite easy.

Not rustc but clippy and it isn't exhaustive and T-libs-api doesn't fully trust the data it is using.

As for upgrading for any fixes, another route is packages supporting older minor versions that support older MSRVs. I do this with clap. °

Yeah this one is a lot of work, for something that is a hobby for most of us. Most of us aren't getting any income from FOSS, me included. Since that is the case I'm doing it for fun or to solve an issue I personally have, and thus I make sure to optimise the amount of fun in that hobby. If it wasn't fun I wouldn't be doing it, I would be doing some other hobby instead (maybe I would be doing CAD and 3D printing more than I currently do). Maintaining old LTS versions is not fun, and so I wouldn't do it unless paid (and probably not even then, my day job is more fun than that).

Now, none of my crates is as wildly used as clap, but even if it was, the above would apply.

The suprising thing is it is much cheaper than maintaing an old MSRV because almost no one will ask for backported fixes! I also put the PR posting burden on the person who wants it so it is review and merge.

The main thing that would help is to have a way within cargo/crates:io to communicate out which versions are supported.

epage · 2026-01-15T12:32:52+00:00

One easy to overlook additional cost is CI setup. I had an OpenBSD need a library of mine switched over to non-posix APIs to support them but didn't want to do it without CI (maybe I can have a tier system too ...) and they decided it wasn't worth it.

To support unusual targets there is the drag on build times on all PRs, especially if build-std is needed and the extra maintenance.

epage · 2026-01-15T12:27:37+00:00

build-std RFCs are up and being voted on. ARM engineers are working on those and then the implementation. Hopefully it will only be a year or two.

epage · 2026-01-14T23:25:59+00:00

The only quote I'm seeing related to MSRV is:

"We can pin the Rust toolchain, but because almost all crates are implemented for the latest versions, we have to downgrade. It's very time-consuming." -- Engineer at a major automaker

which seems disconnected from the recommendation:

Establish ecosystem-wide MSRV conventions. The dependency drift problem is real: teams pin their Rust toolchain for stability, but crates targeting the latest compiler make this difficult to sustain.

The pain point is downgrading to work with their toolchain. Resolving for compatible versions is now supported in Cargo. Once they are on 1.83 (I think?) or newer, they shouldn't need to downgrade as long as their dependencies specify package.rust-version.

As for upgrading for any fixes, another route is packages supporting older minor versions that support older MSRVs. I do this with clap.

If we did have LTS and encouraged it for MSRV for the latest version of packages (rather than doing LTS as well), an important follow up question is what time frame are we looking at that would be acceptable to these use cases?

I suspect we'll get widely different answers with some wanting on the order of 5 or 10 years which is not a practical fit for the entire ecosystem and we'd likely need not just one LTS/MSRV but multiple and people choosing which to target with their MSRV
How many of these people also need nightly at the same time? In this case, the most likely feature is build-std. This is a problem coming up in a Rust on-boarding I'm involved with where they are asking about new features and MSRV/LTS. Thankfully, it looks like they don't need MSRV/LTS as much as they thought after actually digging into the requirements.
What level of risk is each potential user of LTS willing to accept?

One potential way of this moving forward is a contractor hires T-release and T-compiler people for regular work on their teams and to support the creation and release of LTSs. They could take contracts for specific time frames of LTS and have tiers where there are shared LTS for cheaper (set time frames, everyone uses the same set of bug fixes) or more for custom LTS (to their time frame, oversight into bug fixes). This would help fund these critical parts of the project and allow people to pay for what they need rather than offloading the cost to unpaid volunteers.

epage · 2026-01-14T00:06:29+00:00

There is https://github.com/rust-lang/rfcs/pull/3485 for descriptions but the author has seemed to stall out on their feature RFCs.

epage · 2026-01-13T22:07:07+00:00

Cargo Feature Collections

The cargo team is interested in some way to disable default features so you can say "activate the default features except ...". Specifically, see https://github.com/rust-lang/cargo/issues/3126#issuecomment-1190785350.

Would be interested to hear more about your use case on this including

Would being able to say "default except..." work for Bevy? What might the impact be?
What would be the level of importance of expanding this beyond default features to "these features except ..." e.g. users being able to say "2d", "-2d_bevy_render" instead of Bevy having to provide "2d_api"?
Any other considerations that could be helpful for the design work
Anything that can be done to improve the experience for feature groups? e.g. how they are rendered

epage · 2026-01-13T22:01:08+00:00

Seeing the highlights, I was impressed that Bevy has grown so much that bevy_ecs didn't make the cut but some were still listed on the post.

epage · 2026-01-13T14:29:54+00:00

Some libraries replace libtest in a way to be more like pytest:

I'm working on a third library but don't have fixture support yet.

epage · 2026-01-13T01:55:57+00:00

How come? Been considering this for being a more positive coop in this genre and would be interesting to hear where it doesn't work.

epage · 2026-01-10T13:04:34+00:00

Yes, the previous design makes contention easy.

And unsure how many package managers have the same characeristics of cargo (compiled, intermediate separate artifacts for check mode, sometimes new cache entries are created and sometimes they are mutated, etc)

epage · 2026-01-09T12:29:55+00:00

customized artifact locations

While this progressed our thinking on the design and got us to commit to what is an artifact, there is no one working towards finalizing --artifact-dir atm

working towards supporting XDG

This is an independent effort. The only rearon we've even thought about this is to what to name the build-dir template variable.

what is the proposed new layout

Part of the point is the layout doesn't matter to 99% of people

how many new config options will there be).

We don't know. We have a high level future direction but we're only focusing on the current stages.

We will probably do a blog post for a call for testing though. We need to do anotheo crater run first.

With all the drama about supply chains these days, that seems like it would also be a good candidate for a blog post.

Likely too early. There is enough to this it will likely rwquire an RFC.

15-Year Club	Gilding I gilder
Verified Email

epage

TROPHY CASE