Bump tokio to 1.44.2 to fix RUSTSEC-2025-0023

[EliahKagan]

This upgrades tokio from 1.44.1 to 1.44.2 in Cargo.lock to fix the advisory RUSTSEC-2025-0023 ("Broadcast channel calls clone in parallel, but does not require Sync").

This was done with cargo update -p tokio.

[EliahKagan]

I'm not at all clear on why the windows-targets dependency of libloading 0.8.6 is now specified as 0.48.5 instead of 0.52.6, without changing the libloading version or any of its other metadata. (Both are in its allowed range.) All I ran to bump the version of tokio was cargo update -p tokio. Nothing in tokio-1.44.1...tokio-1.44.2 seems to show any obvious reason this would relate to tokio.

Anyway, we depend on lots of different versions of windows-targets separately in Cargo.lock, and it's not clear to me that a higher version is better, since perhaps some higher versions use APIs available on fewer Windows systems? So I suppose this is fine. (For what it's worth, running cargo nextest run --locked --workspace --no-fail-fast on this branch on Windows 10 does not have any build failures, nor any failing tests.)

[Skgland]

While this looks like a valid dependency graph resolution based on [email protected]s version requirement for windows-target which is ">=0.48, <0.53".
Not choosing the latest version already in the dependency graph is unexpected.
Maybe this should be filed as a cargo bug?

[Skgland]

Does it work to just drop this change or does cargo re-generate this change when some command is run?

[EliahKagan]

If I make this change to undo it:

diff --git a/Cargo.lock b/Cargo.lock
index 3a54ce742..d32caad04 100644
--- a/Cargo.lock
+++ b/Cargo.lock
@@ -3654,7 +3654,7 @@ source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "fc2f4eb4bc735547cfed7c0a4922cbd04a4655978c09b54f1f7b228750664c34"
 dependencies = [
  "cfg-if",
- "windows-targets 0.48.5",
+ "windows-targets 0.52.6",
 ]

 [[package]]

Then cargo build --locked, cargo build -r --locked, and cargo nextest run --locked --workspace --no-fail-fast all still succeed and make no changes to Cargo.lock nor to any other tracked files. But running cargo update -p tokio again puts it back to 0.48.5, even while making no change to the version of tokio itself.

Because cargo update -p tokio would change it again, combined with my general reluctance to manually edit Cargo.lock, I am reluctant to put it back unless manually editing Cargo.lock is considered a best practice in this kind of situation (is it?), or unless we can be pretty sure that this cargo update -p tokio behavior is a bug (can we?).

In case it's useful, a commit on top of this with that change made is pushed to run-ci/update-tokio-next on my fork (EliahKagan@6aeba88). I expect that it will pass CI, but even if so, I am still not sure if it's better or worse than what's here currently.

Edit: By the way, I opened this PR because I wasn't sure how long it would be before the RUSTSEC advisory would get a corresponding GitHub Advisory Database advisory. But now there is one (GHSA-rr8g-9fpq-6wmg), and Dependabot is in progress now in creating a Dependabot security update PR for it. Assuming it succeeds at creating the PR and the changes there don't look clearly wrong, I may simply let that supersede this PR.

[EliahKagan]

I'll let the Dependabot PR #1941 supersede this. It makes the same change to the version, listed for libloading, of windows-targets as discussed in #1938 (review). But for the reasons given there I'm reluctant to manually change that back. That Dependabot also produces it indicates that at least it wasn't specific to anything broken or unusual on my local machine.