STR:

• Change a crate SHA in toolkit/library/rust/shared/Cargo.toml
• Run mach vendor rust

Expected:

• The crate is updated

Actual

• The crate is update, and third_party/rust/nom/{.travis.yml,.cargo-checksum.json} are deleted or recreated, depending on if they were present or not.

This reproduces on an ArchLinux machine and on a macOS 10.15, and can be reproduced by doing cargo vendor third_party/rust from the top level of mozilla-unified.

cargo --version
cargo 1.41.0 (626f0f40e 2019-12-03)

This reproduces on an ArchLinux machine and on a macOS 10.15, and can be reproduced by doing cargo vendor third_party/rust from the top level of mozilla-unified

Sounds like you described a bug in cargo vendor... (implying this should be filed against cargo)

To try to reproduce this, I changed the revision sha of mp4parse-rust from 0dc3e6e7c5371fe21f69b847f61c65fe6d6dc317 to 309b9b8acdafa1fc34bb6e3df5b27979b272bf42. Afterwards, I ran ./mach vendor rust --ignore-modified.

Finally, I checked what files were changed:

$ hg status
M .cargo/config.in
M Cargo.lock
M python/mozbuild/mozbuild/vendor/vendor_rust.py  # changed by me due to the license of qlog
M third_party/rust/mp4parse/.cargo-checksum.json
M third_party/rust/mp4parse/src/boxes.rs
M third_party/rust/mp4parse/src/lib.rs
M third_party/rust/mp4parse/src/tests.rs
M third_party/rust/mp4parse/tests/public.rs
M third_party/rust/mp4parse_capi/.cargo-checksum.json
M third_party/rust/mp4parse_capi/src/lib.rs
M third_party/rust/mp4parse_capi/tests/test_encryption.rs
M toolkit/library/rust/shared/Cargo.toml

nom doesn't appear to be changed here, looks like I did something different than you.
Which package's sha did you change? Does that package depend on nom?

cubeb-coreaudio and cubeb-pulse seem to both depend transitively on nom, and I change one or the other rather frequently.

Aha, I'm able to reproduce the issue recreate the .travis.yml and .cargo-checksum.json files being added by changing the revision of cubeb-pulse. I'll dig in 👍

Playing with this further, I'm able to see that, when nom is re-vendored, the .cargo-checksum.json and .travis.yml files are added.
Indeed, creating a new, standalone cargo project, depending on nom = "=5.1.1" and vendoring produces the same result - the .cargo-checksum.json and .travis.yml files are present.

I'm struggling to see them get deleted, though. Within m-c, if I change the hash of cubeb-pulse again, the .cargo-checksum.json and .travis.yml files remain.

Are you sure that they're being deleted by running ./mach vendor rust again? I'm unsure, because:

• A fresh "vendor" shows that the files should be part of the package
• The other vendored rust packages all have .cargo-checksum.json
• I'm unable to make them get deleted locally

Perhaps the files just failed to get committed when nom was vendored last?

There's an interesting pattern with those files from nom in the mozilla-central history: they are removed when @arai updates something, and re-added when someone else updates something else.

@arai, what's your setup? Are you on Windows, by any chance?

I'm on macOS 10.15.5, with encrypted APFS volume (case insensitive).
I tried updating jsparagus crate revision and re-run mach vendor rust.
I don't see nom-related files modified there.

I recently updated cargo version to 1.44.1, and when the last time I submitted patch, I used older version.
I don't remember the exact version, but maybe from months ago.

So, if I go back to the last time @arai landed some update, which is 2592f69b97c5dfc5f904696d69c615dbd5a5bfeb, and I cargo vendor third_party/rust with cargo 1.41.0, I get no change (as in, the missing files stay missing). If I use cargo 1.42.0, then the files are created.

If I go back to the last time someone else updated, which is b506158b8759db4bd7a44a8a364ec7dcd3956655, and cargo vendor third_party/rust with cargo 1.41.0, then the files are altered. They are restored if I switch to cargo 1.42.0.

So this is a cargo vendor problem in 1.41 that was fixed in 1.42.

1.38 changed the Cargo.lock format, and the current minimum (1.37) can't
read it, so the minimum version was already wrong.

1.41 has a problem vendoring nom for some reason, that appears to be
fixed in 1.42.

Clearing NI, thanks for the fix!

Not sure it's a complete fix, though, because @njn says he's experiencing the problem with 1.43, but I can't reproduce. I can only reproduce reliably with 1.41.

https://hg.mozilla.org/mozilla-central/rev/8abffeca377d