Weekly cargo update of dependencies
#900
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
obi1kenobi
added a commit
that referenced
this pull request
Sep 2, 2024
Resolves a variant of #167 described here: #167 (comment) This issue was observed during a CI run of #900, where an older tokio-stream version was using a brand-new tokio with stronger guarantees: several types had newly become `UnwindSafe`. Since the baseline tokio-stream was a registry version, it was using a fresh lockfile with the latest dependencies. The current arm, meanwhile, was a path dependency fixed to a specific commit, where cargo had decided to reuse an older version of tokio without the `UnwindSafe` trait on those types. This presented as a (phantom) breaking change: the older tokio-stream's types were `UnwindSafe` due to auto-trait propagation from a newer tokio while the newer tokio-stream with an older tokio did not have that trait. The solution is to explicitly run `cargo update` inside path dependency workspaces we create. This way, both path dependency and index-based rustdoc JSON generation happens with the latest versions of the target library's own dependencies.
obi1kenobi
added a commit
that referenced
this pull request
Sep 2, 2024
Resolves a variant of #167 described here: #167 (comment) This issue was observed during a CI run of #900, where an older tokio-stream version was using a brand-new tokio with stronger guarantees: several types had newly become `UnwindSafe`. Since the baseline tokio-stream was a registry version, it was using a fresh lockfile with the latest dependencies. The current arm, meanwhile, was a path dependency fixed to a specific commit, where cargo had decided to reuse an older version of tokio without the `UnwindSafe` trait on those types. This presented as a (phantom) breaking change: the older tokio-stream's types were `UnwindSafe` due to auto-trait propagation from a newer tokio while the newer tokio-stream with an older tokio did not have that trait. The solution is to explicitly run `cargo update` inside path dependency workspaces we create. This way, both path dependency and index-based rustdoc JSON generation happens with the latest versions of the target library's own dependencies.
obi1kenobi
added a commit
that referenced
this pull request
Sep 2, 2024
Resolves a variant of #167 described here: #167 (comment) This issue was observed during a CI run of #900, where an older tokio-stream version was using a brand-new tokio with stronger guarantees: several types had newly become `UnwindSafe`. Since the baseline tokio-stream was a registry version, it was using a fresh lockfile with the latest dependencies. The current arm, meanwhile, was a path dependency fixed to a specific commit, where cargo had decided to reuse an older version of tokio without the `UnwindSafe` trait on those types. This presented as a (phantom) breaking change: the older tokio-stream's types were `UnwindSafe` due to auto-trait propagation from a newer tokio while the newer tokio-stream with an older tokio did not have that trait. The solution is to explicitly run `cargo update` inside path dependency workspaces we create. This way, both path dependency and index-based rustdoc JSON generation happens with the latest versions of the target library's own dependencies.
Locking 14 packages to latest compatible versions
Updating cargo-config2 v0.1.27 -> v0.1.29
Updating cc v1.1.14 -> v1.1.15
Updating filetime v0.2.24 -> v0.2.25
Updating indexmap v2.4.0 -> v2.5.0
Updating jiff v0.1.10 -> v0.1.12
Updating object v0.36.3 -> v0.36.4
Updating quinn v0.11.3 -> v0.11.4
Updating quinn-proto v0.11.6 -> v0.11.7
Updating rustc_version v0.4.0 -> v0.4.1
Updating rustix v0.38.34 -> v0.38.35
Updating rustls-webpki v0.102.6 -> v0.102.7
Updating syn v2.0.76 -> v2.0.77
Updating tokio v1.39.3 -> v1.40.0
Updating webpki-roots v0.26.3 -> v0.26.5
note: pass `--verbose` to see 60 unchanged dependencies behind latest
github-actions
bot
force-pushed
the
cargo_update
branch
from
9d15dc3 to
447554d
Compare
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Automation to keep dependencies in
Cargo.lockcurrent.The following is the output from
cargo update:Locking 14 packages to latest compatible versions Updating cargo-config2 v0.1.27 -> v0.1.29 Updating cc v1.1.14 -> v1.1.15 Updating filetime v0.2.24 -> v0.2.25 Updating indexmap v2.4.0 -> v2.5.0 Updating jiff v0.1.10 -> v0.1.12 Updating object v0.36.3 -> v0.36.4 Updating quinn v0.11.3 -> v0.11.4 Updating quinn-proto v0.11.6 -> v0.11.7 Updating rustc_version v0.4.0 -> v0.4.1 Updating rustix v0.38.34 -> v0.38.35 Updating rustls-webpki v0.102.6 -> v0.102.7 Updating syn v2.0.76 -> v2.0.77 Updating tokio v1.39.3 -> v1.40.0 Updating webpki-roots v0.26.3 -> v0.26.5 note: pass `--verbose` to see 60 unchanged dependencies behind latest