(Un?)intentional changes in re-serialization of Cargo.toml (during `cargo package`) in nightly?

It looks like recent nightly Rust has changed the way Cargo.toml is re-serialized? The order of tables seems to have changed, as can be seen here:

https://diff.rs/reqwest/0.12.9/reqwest/0.12.10/Cargo.toml

Was this an intentional change? I don't see anything that would explain this in the pending release notes: cargo/CHANGELOG.md at master · rust-lang/cargo · GitHub

Seems like this here might have had that effect

cc @epage

4 Likes

FWIW, I'd consider that the only thing stable in the repackaged manifest is the data model object, and details that don't logically change that are irrelevant. That's the purpose of using a self-describing format.

Stable field/table order is simpler for bespoke ad-hoc parsing, but the end result of that ossification is never adding any new fields, since that relocates the other fields. The generated post-processed manifest is tool-facing; use a proper TOML parser.

3 Likes

Sure. I didn't mean to imply that this was a breaking change, just wanted to know whether it was intentional or not. This won't cause problems for us in Fedora packaging - we use cargo metadata to get crate metadata in a guaranteed-stable JSON format. The only annoying thing this will cause is that rebasing some patches for Cargo.toml that we carry downstream will be more annoying (but even then, only once).

1 Like

As you can see in the linked PR, we track the exact details of the generated manifest so its known when a change affects that.

Our main concern for making changes is mninmizing version-related changes for cargo vendor users. That doesn't mean we can't make changes. For example, back in May or so we explicitly enumerated all build targets and a couple months back we added package.autolib. I wouldn't be suprised if we did another re-order in the last couple of years.

3 Likes

Thank you for confirming!

Previous changes to the format of Cargo.toml generated by cargo package were usually just additions (like the explicit enumeration of build targets) or minor changes to ensure consistent ordering of things. This change looked like a "bigger" one (reordered "features" table before dependencies, for example), so I just wanted to know whether it was intentional.

As I said, we don't read Cargo.toml directly, our tools use the stable cargo metadata JSON output instead. The only way in which this affects us is that some if our patches will fail to re-apply on rebase, and will need to be manually rebased.

There is an potential implication I want to clear up in emphasizing "the stable cargo metadata JSON output". The manifest is also stabde. We can make the changes we have because TOML is defined as unordered and we can add content that doesn't change how it is evaluated.

Just FYI pending changelog usually updates once per Rust release only. Some nightly changes won't show until that.

You can check GitHub milestones to get a glimpse of actual changes in a release Milestones - rust-lang/cargo · GitHub