Update dependencies

[smoelius]

Is there a mechanism for keeping Clippy's dependencies up to date? If so, this PR can likely be ignored.

I ask because several of the dependencies look dated.

This PR updates them via:

find . -name Cargo.toml -not -path "./tests/*" -exec cargo upgrade --workspace --manifest-path={} \;

Some small changes to the cargo_common_metadata lint were needed because cargo_metadata 0.14.0 uses UTF8 paths.

changelog: update dependencies

[rust-highfive]

r? @camsteffen

(rust-highfive has picked a reviewer for you, use r? to override)

[camsteffen]

I don't think we should add the patch version to any dependency versions unless there is a reason to. For example, serde = "1.0" is the same as serde = "^1.0" and so 1.0.129 is already included. So that would make a lot of these changes unnecessary.

Other than that, I looked over the updates and they seem fine to me. Maybe we should do this in the rust repo to make sure it doesn't break CI? @rust-lang/clippy do we have a procedure for this or any other concerns?

[Manishearth]

Yeah I would do this in the rust repo and ensure we're not bumping deps used by the rest of rust. OTOH it should be fine to bump our lockfile deps to the versions in rust's lockfile

[flip1995]

I also wouldn't include the patch version.

And before merging this, we have to make sure, that it doesn't break things in the Rust compiler. So either make this update directly in rust-lang/rust or do a dummy sync of this PR and test it there.

[smoelius]

I don't think we should add the patch version to any dependency versions unless there is a reason to.

Should this PR be updated to remove the patch versions from dependencies that already have it?

Maybe we should do this in the rust repo to make sure it doesn't break CI?

Sorry if I am being dense, but I should submit an analogous PR for this subtree of the rust repo? https://github.com/rust-lang/rust/tree/master/src/tools/clippy

[flip1995]

Should this PR be updated to remove the patch versions from dependencies that already have it?

That depends on how this update behaves in rust-lang/rust I guess. Some may be necessary, to not duplicate dependencies, I guess.

Sorry if I am being dense, but I should submit an analogous PR for this subtree of the rust repo?

Yes, exactly. You will also have to run cargo update -p clippy in the rust repo after updating the dependencies. This will update the Cargo.lock file in the Rust repo. As many deps as possible should still be shared with other projects / the rust compiler.

[smoelius]

It prepared a patch using git diff and applied it to the src/tools/subdirectory. The patch applied cleanly everywhere, except at lintcheck. For its Cargo.toml, I had to make the changes manually.

I prepared a second patch after removing the patch versions with:

find . -name Cargo.toml -not -path './tests/*' -exec sed -i '/^\[dependencies\]$/,$ s/\(= "[[:digit:]]\+\.[[:digit:]]\+\)\.[[:digit:]]\+\("\)/\1\2/' {} \;

With the patch versions, tinyvec_macros had to be added to the tidy tool. Without the the patch versions, this was not necessary.

From what I can tell, there were no other hitches with either of the rust PRs. Both are linked above.

Please note that the current PR still includes the version numbers. Though, it's a trivial matter for me to remove them.

[flip1995]

Since we need a coordinated update for some of the deps with other tools, we practically have to do this directly in the Rust repo. So I'm closing this in favor of rust-lang/rust#88517. Let's continue further discussion and reviews there.

[kornelski]

@camsteffen Serde crate intentionally violates semver rules, and regularly adds new public APIs in "patch" releases. As a result, it's not reliable to specify serde's version as serde = "1" or serde = "1.0", beacause serde = "1.0.0" is has a different public API than serde = "1.0.160".

[flip1995]

We don't really use serde that extensively, so we don't expect to be hit by any API changes. We only use it to parse the clippy.toml file and internally to generate the lint documentation.

Just defining serde = "1.0" has the advantage that we won't run in a situation where serde is duplicated in the rust-lang/rust repo Cargo.lock file, because we need a different specific version than other tools/rustc itself.

[kornelski]

Cargo doesn't support duplicating dependencies within the same semver-major version range, so you will never get a duplicate from specifying feature/patch version. Version specified in Cargo.toml is not even the version that will be used, but merely the minimum acceptable version. Omitted digits also don't have any meaning either. serde="1.0" parses as serde="^1.0.0". And you need to be careful, because serde doesn't use semver, so 1.0.0 is incompatible with 1.0.160.