This also blocks updating the git2 (now at 0.16) and crates-index (now at 0.19) dependencies:

The git2 0.16 bump (like the 0.15 bump) is mostly backwards compatible, so we could just expand the range to >=0.15, <0.17 (like we did in #662), but given that crates-index 0.19 takes a git2 = "0.16" dependency, there wouldn't be an advantage to doing so as Cargo would always be forced to pick 0.16 anyway. 0.18.11 does permit all the versions of git2, so you could bump git2 first and then crates-index if you'd prefer to split them up.

The crates-index bump is just for a bump of toml and git2, so should be an easy upgrade.

@jonhoo bumping git2 is blocked on cargo-edit updating from v0.14: killercup/cargo-edit#770

Also, this PR is blocked on finding a replacement for cargo_edit::LocalManfiest::upgrade, as used here

Ah, great, thanks for the breadcrumb trail!

Looks like cargo-edit bumped git2 yesterday in killercup/cargo-edit#833, it just hasn't been released to crates.io yet.

Cool, hopefully there will be a release soon which will unblock the other updates

Speak of the devil. 0.11.8 is out: https://crates.io/crates/cargo-edit/0.11.8

Cool, so to get this over the line we just need to figure out a replacement for LocalManifest::upgrade as mentioned above

If the implementation of it just uses publicly-available APIs, I guess you could just copy-paste that code from the old version?

That calls update_table_named_entry which is also gone in the latest release

I opened an issue here: killercup/cargo-edit#837

So I guess the way to go (at least in the short term) then is to copy-paste in both the upgrade method and any other internal method dependencies. Long-term, it's to move away from depending on the library API of cargo-edit.

I forked cargo-edit to cargo-edit-9 - we may just use that temporarily I guess
PR here:

• rustsec: Fix git2 via cargo-edit-9 fork #831