Semver errors when exposing types from 3rd party crates that are not at the latest version #167
Comments
|
Thanks for the bug report, and apologies for the inconvenience. It's either the bitflags macro, or the OS-specific The latter hypothesis would make this similar to #147. If so, the same workaround might apply: instead of using the index to find the previous version (the default behavior), explicitly a give a git revision to check against: https://github.com/obi1kenobi/cargo-semver-check#does-the-crate-im-checking-have-to-be-published-on-cratesio I'd love to know if the workaround did the trick! In the meantime, I'll look at the rustdoc JSON output. |
|
I'm having a bit of trouble reproducing this bug, on both v0.12.0 (the version you seemed to be using) and v0.12.1 (the most recent release), on both stable Rust and nightly: Here are a few more pieces of information that you might be able to provide that would be a big help in tracking this issue down:
|
Software versioncargo-semver-checks 0.12.1 Operating systemMac OS X 10.15.6 (Darwin 19.6.0) Command-line/Users/jrmuizel/.cargo/bin/cargo-semver-checks semver-checks --bugreportcargo nightly versionCompile time information
|
|
Thank you so much! And since |
|
I get the same on 1.64 stable. |
|
and on |
|
Fascinating, thanks for confirming. I'm working to get to the bottom of this and will post more info here when I have it. Apologies once again for the inconvenience — this is not the kind of user experience we want in |
|
What OS did you try to reproduce it on? |
|
macOS 10.15.7 on an x86 CPU, almost identical to your system (10.15.6 on x86) |
|
So, if I run it on a fresh checkout I'm also not able to reproduce. I guess it could be a difference in the Cargo.lock file. |
|
If you run |
|
Ah thank you for narrowing down the exact details. I'll try that! |
|
Sorry for the delay. In the last couple of weeks I lost my ability to test on a macOS device, and I was having difficulty even compiling After a bit of investigation, it appears that the reported errors are correct i.e. true positives:
To recap: downgrading Please let me know your thoughts! |
|
Would it be possible to build the current version without using the local |
|
Unfortunately, I don't think so. The current version rustdoc information (which You may be able to work around this on your end by running something like: It's also worth considering that the semver issue uncovered here can also arise in actual usage as well:
If the above scenario is a concern, it may be worth specifying a newer minimum version bound on |
|
Is there anything else I could do to help you out with this? Were you able to adopt cargo-semver-checks for your project? If not, I'd love to work with you to figure out how we can do better in the future. |
|
I filed #193 about another issue I'm having. |
This comment was marked as outdated.
This comment was marked as outdated.
obi1kenobi
changed the title
|
I just had an idea that might help solve this problem rather elegantly, if it works. We currently generate the "current" rustdoc JSON directly from the crate's codebase itself, which makes that rustdoc subject to the codebase's lockfile. The "baseline" rustdoc is generated via its own temporary crate that declares an exact dependency on the baseline version, using a new lockfile which therefore may pull in newer versions of dependencies. Could we generate the "current" rustdoc JSON via a temporary crate that declares a path dependency on the current version but as a result also uses a freshly-generated lockfile? To avoid an analogous problem with git and local path baselines, we should consider using a temp crate + path dependency for those baseline types as well. In general, if this approach works then we should generate all rustdoc JSONs through a temp crate. cc @tonowak — what do you think? |
|
Hey @jrmuizel! If you have a chance, could you check if the current version on @tonowak and I just merged what we believe should be a fix, but we don't have a way to test it since neither of us has an Apple device nor a lockfile with non-latest dependency versions. We'd love to know if it indeed fixed the issue or if we need to do something else as well to get this use case unblocked. |
|
It does resolve the issue. When I run |
|
Awesome, thanks for confirming and for bearing with us while we worked on it! The fix will be published in v0.18 sometime in this coming week. Are there any other blockers toward adopting |
|
Fixed by #341, released as v0.18.0. |
|
Apparently making a separate manifest and taking a path dependency on the library to check is unreliable too. In #900, we're seeing the path dependency use an outdated version of We have to run The new issue is tracked by #902. |
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.
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.
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.
Scenario:
Ahas a dependency on crateB = "1.0"and exposes crateB's types in its own public API.Acurrently usingBversion1.0. Version1.1ofBexists and contains additional pub methods on its pub types.Ais semver-checked using the default (registry-based) baseline:B v1.0and will show the v1.0 methods fromBas part ofA's public API.Awill be generated, which will cause a new lockfile to be created with the latest allowed version ofB: v1.1.Awill show additional methods that don't exist in the current version: those added inB v1.1but not present in `B v1.0.Steps to reproduce the bug with the above code
Checkout https://github.com/servo/core-foundation-rs/tree/cocoa-v0.24.1/cocoa
Run
rustup run nightly cargo semver-checks check-releaseActual Behaviour
Expected Behaviour
No changes should be found when no changes have been made
Additional Context
It seems like things are getting confused by the bitflags macro
Debug Output
No response
The text was updated successfully, but these errors were encountered: