Consider reintroducing `Cargo.lock` files to this repository

https://github.com/rust-lang/rust-clippy/pull/17645 made me realize we don't have a Cargo.lock (except for the lockfile in clippy_test_deps). Why?

Well, in 2018, oli-obk said in response to an issue suggesting a lockfile be added:

We can't do this due to the rustc integration, where we are in the rustc workspace. we used to have it but removed it during the merger

If we look a little further back, we can find the PR that removed the lockfile in 2017. It links to a comment on the PR that added clippy to the rust-lang/rust repository by alexcrichton, which says:

In https://github.com/rust-lang/rust/pull/45285#issuecomment-337357481 I've discovered something slightly more worrisome (but perhaps not so bad in the long run?). Right now clippy is its own workspace with its own Cargo.lock, but in general we're trying to get all our tools into the same workspace to ensure dependencies are the same. This is mostly a problem for dependencies like Cargo where we don't want the cargo executable and the RLS to be using two versions of Cargo, we'd rather ensure that everything is using the same source code.

Folding clippy into the rustc workspace is difficult, however, because clippy itself is already a workspace. I'm not sure how to best solve this...

I believe the only downside of allowing clippy to have its own Cargo.lock is that it may pick up different versions of dependencies than the rest of the tools in the Rust repo. This means larger build times for us (as we're probably building different versions). If clippy were to pick up a dependency on larger tools (aka rls, rustfmt, cargo, etc), then we'd run the risk of version drift. I don't think there's plans for that though?

If we follow the conversation a bit more, though, we see Manishearth respond:

If clippy were to pick up a dependency on larger tools (aka rls, rustfmt, cargo, etc), then we'd run the risk of version drift. I don't think there's plans for that though?

Nope.

I think clippy doesn't particularly need a lockfile, really. It's fine if y'all use your own.

To which alexcrichton replied:

Oh the worry is less so about lock files but the fact that clippy is its own workspace (so it's not a member of the main rustc workspace)

Which seems to suggest removing the lockfile was never really necessary to begin with. Is there any reason for us to not have a lockfile in this repository at this point? As of writing this, the latest cargo subtree has a lockfile checked in. This repository isn't a workspace anymore, so I don't think there's anything stopping us? It would be nice to have a lockfile checked in, particularly to help protect contributors from supply-chain attacks.

For the sake of documentation, additional discussion of this issue has taken place in the following Zulip topics:

• #t-clippy > Failing CI
• #t-cargo > How does rust-lang/cargo keep its lockfile in sync?

Start by inspecting the repository's Cargo manifests and the existing clippy_test_deps/Cargo.lock, then review the linked history about Clippy's workspace integration. Check the linked Zulip discussions for current CI and lockfile-sync constraints. Done means determining whether a repository lockfile is compatible with the current layout and documenting or implementing the agreed approach.