Closed obi1kenobi closed 1 year ago
It seems that the libp2p-gossipsub-v0.44.0
tag is actually in the future relative to the affected hash (3ec7c79
). This is strange since the affected hash already shows v0.44.0 in the Cargo.toml
for that package. Does your workflow perhaps cause updates to the version number in Cargo.toml
before the version is published?
Bisection shows that this is the commit where the semver violation stops being reported: https://github.com/libp2p/rust-libp2p/commit/caed1fe2#diff-368386d6c30a7eb4d60fcddda689bba01e9e215451a387fa58ff93b12fb914de
I noticed at https://crates.io/crates/libp2p-gossipsub/versions that v0.44.0 was just released ~16h ago, so I'm guessing that libp2p-gossipsub
uses "future versioning" where the Cargo.toml
version number may either be the most-recently-released version or a still-unreleased version.
In that case, there's no semver violation here since the baseline ("crates.io 0.44.0") is actually newer than the "current" (the git hash in question).
But there is a hazard for a future semver violation that you may not have noticed: the Behaviour
type is now Sync
(as of the bisected commit), and semver requires a major version if it ever stops being Sync
. This is a good example of something that might be a good warn
-level API evolution lint for the future.
uses "future versioning" where the
Cargo.toml
version number may either be the most-recently-released version or a still-unreleased version.
Yes we bump the version as part of PRs to ensure we don't forget that there was a breaking change. I do want to change that though, see https://github.com/libp2p/rust-libp2p/issues/2902.
But there is a hazard for a future semver violation that you may not have noticed: the
Behaviour
type is nowSync
(as of the bisected commit), and semver requires a major version if it ever stops beingSync
. This is a good example of something that might be a goodwarn
-level API evolution lint for the future.
Damn. Sometimes I wish auto-traits wouldn't exist in Rust and you would just have to write #[derive(Send, Sync)]
.
libp2p-gossipsub
at commit hash3ec7c797
has begun failing semver-checks due to a presumed upstream dependency semver violation. Auto-traits are viral, so the upstream break leaks intolibp2p-gossipsub
's own public API and breaks its semver too:To find the problem, I've added this small snippet of code in
behaviour.rs
that will cause a compilation error with a pretty error message:Compiler error output
``` Checking libp2p-gossipsub v0.44.0 (/.../rust-libp2p/protocols/gossipsub) error[E0277]: `(dyn muxing::boxed::AsyncReadWrite + std::marker::Send + 'static)` cannot be shared between threads safely --> protocols/gossipsub/src/behaviour.rs:207:16 | 207 | send_check(b) | ---------- ^ `(dyn muxing::boxed::AsyncReadWrite + std::marker::Send + 'static)` cannot be shared between threads safely | | | required by a bound introduced by this call | = help: the trait `Sync` is not implemented for `(dyn muxing::boxed::AsyncReadWrite + std::marker::Send + 'static)` = note: required for `Unique<(dyn muxing::boxed::AsyncReadWrite + std::marker::Send + 'static)>` to implement `Sync` = note: required because it appears within the type `BoxI am not currently seeing this problem on the current tip of
master
(1a9cf4f7760724032b729c43165716c7ecd842ad
).To be honest, I'm not exactly sure how that's possible, since the problematic commit only started failing in the last 48h — I know because it's part of the
cargo-semver-checks
integration suite and it wasn't failing 48h ago but failed now: https://github.com/obi1kenobi/cargo-semver-checks/actions/runs/4267893704/jobs/7429959838This is very unusual, and probably worth investigating. I'd love your help!