Open obi1kenobi opened 1 week ago
The invocation of cargo-semver-checks
that triggers the false-positives is this:
$ cargo semver-checks --manifest-path ../tokio/tokio-stream/Cargo.toml --release-type minor --exclude benches --exclude examples --exclude stress-test --exclude tests-build --exclude tests-integration
Finished `release` profile [optimized] target(s) in 0.18s
Running `target/release/cargo-semver-checks semver-checks --manifest-path ../tokio/tokio-stream/Cargo.toml --release-type minor --exclude benches --exclude examples --exclude stress-test --exclude tests-build --exclude tests-integration`
Parsing tokio-stream v0.1.12 (current)
Parsed [ 0.869s] (current)
Parsing tokio-stream v0.1.12 (baseline, cached)
Parsed [ 0.039s] (baseline)
Checking tokio-stream v0.1.12 -> v0.1.12 (assume minor change)
Checked [ 0.014s] 80 checks: 79 pass, 1 fail, 0 warn, 7 skip
--- failure auto_trait_impl_removed: auto trait no longer implemented ---
Description:
A public type has stopped implementing one or more auto traits. This can break downstream code that depends on the traits being implemented.
ref: https://doc.rust-lang.org/reference/special-types-and-traits.html#auto-traits
impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.34.0/src/lints/auto_trait_impl_removed.ron
Failed in:
type ReceiverStream is no longer UnwindSafe, in /.../tokio/tokio-stream/src/wrappers/mpsc_bounded.rs:11
type ReceiverStream is no longer RefUnwindSafe, in /.../tokio/tokio-stream/src/wrappers/mpsc_bounded.rs:11
type UnboundedReceiverStream is no longer UnwindSafe, in /.../tokio/tokio-stream/src/wrappers/mpsc_unbounded.rs:11
type UnboundedReceiverStream is no longer RefUnwindSafe, in /.../tokio/tokio-stream/src/wrappers/mpsc_unbounded.rs:11
Summary semver requires new major version: 1 major and 0 minor checks failed
Finished [ 0.966s] tokio-stream
cc @Darksonn on the off chance you notice this while working on tokio
.
Scanning on new tokio
versions should be fine, since the path dependency on tokio
will point past 1.40.0. But re-scanning older commits can trigger this.
If you have opinions the cargo
behavior, or ideas on how to get it to update transitive path dependencies to latest compatible versions, I'd love to hear them!
Interesting. Our CI job doesn't get any lock file as input, so I don't think we will hit this.
It sounds like the proper solution would be for tokio-util to use the local Tokio in both builds being compared?
I agree, I don't think you'll hit it either. Just wanted to preemptively warn you just in case, so you don't end up debugging a phantom breaking change.
Yes, we'll have to figure out a way to use the same version of tokio
(and all other dependencies) on both sides of the comparison. Otherwise it's apples to oranges. I'm hoping we can somehow get cargo
to use the version number from the transitive dependency, instead of the path component of the transitive path dependency. But I haven't figured out a way to do that yet.
Thanks for the heads up. I guess it could potentially affect our branches used for making backports to LTS releases.
Steps to reproduce the bug with the above code
When specifying a package by path dependency,
cargo
is only willing to use that package's own declared path dependencies and ignores newer SemVer-compatible dependency versions. It refuses to update to newer versions even if explicitly asked withcargo update
or evencargo update --precise
.This causes false positives. For example:
tokio v1.40
made some types newly becomeUnwindSafe
.tokio-stream
's types newly becomeUnwindSafe
across a variety oftokio-stream
versions when used withtokio v1.40
.tokio-stream
now results in false positives:tokio-stream
, for whichcargo
resolves thetokio
dependency to1.40
. That means the baseline's types areUnwindSafe
.tokio-stream
is a path dependency, for whichcargo
chooses the path dependencytokio
version. Thattokio
is older than 1.40, so its types aren'tUnwindSafe
. As a result, thetokio-stream
types aren'tUnwindSafe
either.tokio-stream
had`UnwindSafe
types, and the newer one did not, this is reported as a breaking change!cargo update
inside the placeholder project we generate when creating rustdoc JSON fortokio-stream
(where we have a path dependency to it) would result in newertokio
. This is not the case, due to the issue described at the top.Repro:
Actual Behaviour
Two items:
(1) There should be a way to run
cargo update
inside a project with a path dependency to force it to use latest SemVer-compatible versions of dependencies.(2)
cargo update --precise 1.40.0 tokio
should either upgradetokio
to 1.40.0 as requested, or should exit with an error. It should not completely ignore the 1.40.0 argument and exit cleanly.Expected Behaviour
(1)
cargo update
silently does not update versions of path dependencies of a path dependency. Instead, it pins the path dependencies and their path dependencies exactly. There does not appear to be a way to override this.The first
cargo update
run after the setup above may update some non-path-related dependencies. Subsequentcargo update
runs will look like this, and will not upgradetokio
to 1.40.0 nor mention it in any way.(2)
cargo update --precise 1.40.0 tokio
completely ignores the--precise 1.40.0
requirement, and exits cleanly as a no-op.Generated System Information
Software version
cargo-semver-checks 0.34.0
Operating system
Linux 5.15.153.1-microsoft-standard-WSL2
Command-line
cargo version
Compile time information
Build Configuration
No response
Additional Context
No response