Cargo-edit: Some cargo.toml gets scrambled when runing cargo upgrade

Created on 19 Jul 2018  路  5Comments  路  Source: killercup/cargo-edit

I ran cargo upgrade parking_lot --all

Most helpful comment

I believe this is resolved in #312. Feel free to reopen if it's not the case.

All 5 comments

hey @Eijebong, yes it's a known limitation of the underlying toml library we currently use in cargo-edit. It would be fixed when/if we switch to tom.

Sure, I spoke to @killercup who told me to open this to check that the switch would fix these cases

I was just talking to the maintainer of combine (which is used by cargo_edit) on gitter, and I reckon that if we store a list of start+end positions for each table in the tree then we could serialise unmodified tables/table-fragments back in their original form+position. This could potentially be done without replacing cargo-edit.

You'd still have this class of bug if you try to edit a fragmented table, but it should be possible to emit a warning (or flat-out fail and require a --regroup flag) in that case, because needing to programmatically edit such tables would be very rare.

Does this sound like a sensible idea?

While I was busy procrastinating actually starting on the above plan, I cloned rust-lang/rust-repos and went hunting for Cargo.toml examples on github. I found 80164 Cargo.toml files in the roots of git repos. I cleaned up DOS line endings and missing final newlines manually.

I then used cargo add to add a dependency.

Of the 80164 samples I found:

  • 2310 were virtual manifests
  • 54 were invalid syntax
  • 69455 (87%) just added a single line (as expected)
  • 6889 (9%) also added a [dependencies] section (still fine)
  • 1457 (2%) also did something else (mostly moving sections of the file around, but ~10 also made whitespace changes, like removing spaces from section headers)

I've dumped a list of links to the 1457 files at https://raw.githubusercontent.com/alsuren/rust-repos/cargo.toml-samples/largest-diffs-last.urls . The files with the smallest diff are at the top, and the largest diffs are at the bottom. The use-case that regularly produces large diffs is having a [package.metadata.deb] or [package.metadata.release] or [package.metadata.bootimage] section at the bottom of the file.

I have a day off on Wednesday, so I might have a go at tackling this then. Alternatively I could tackle #217 first, because it's probably easier, even though I only found 191 files where there are more instances of = *' than = *".

I believe this is resolved in #312. Feel free to reopen if it's not the case.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

killercup picture killercup  路  19Comments

joshtriplett picture joshtriplett  路  8Comments

jcgruenhage picture jcgruenhage  路  7Comments

Dowwie picture Dowwie  路  7Comments

ordian picture ordian  路  29Comments