cargo-semver-checks
cargo-semver-checks copied to clipboard
obi1kenobi
Prototype for simultaneous support of multiple rustdoc format versions.
Prototype for supporting multiple rustdoc format versions in the same version of cargo-semver-checks (related to #126). Intended for discussion, and not planned to merge as-is.
It supports rustdoc JSON format v18 and v21, and will happily deserialize either file format. However, the baseline and current JSON files must have the same version -- no mixing and matching is allowed. This constraint is not a problem for the GitHub Action or the common ways of using cargo-semver-checks from the terminal.
I'm strongly considering splitting out the version-specific rustdoc_vX directories (containing the Trustfall adapters for each format version) into their own crate, which for ease of use could have major version X compatible with rustdoc JSON format version X. Another crate could perhaps include the "choose whichever version makes sense" functionality and provide a Box<dyn Adapter> for Trustfall querying. This would probably be useful outside of cargo-semver-checks since this is not the only use case for querying rustdoc JSON.
I broke and/or deleted most of the tests but I tested this by hand with v18 and v21 files, and it works as designed:
- v18 current and v18 baseline works
- v21 current and v21 baseline works
- mix-and-match files produce an error, the expectation being that the files are generated by the same-ish rustdoc version and therefore have the same format number
@epage if you have a second, I'd love your thoughts on whether this is worth pursuing and whether this approach makes sense or if there's something better we should do instead.
So long as we aren't distributed with rustup, I think this is worth pursuing.
I also think its worth reconsidering using stable rust with RUSTC_BOOTSTRAP as that will produce less churn, not require users to have an extra toolchain, and give us more time to support a rustdoc version.
I also think its worth reconsidering using stable rust with RUSTC_BOOTSTRAP as that will produce less churn, not require users to have an extra toolchain, and give us more time to support a rustdoc version.
RUSTC_BOOTSTRAP is an interesting idea. If I'm understanding correctly, it would allow us to stay on stable with whatever rustdoc JSON format version that stable produces, and we'd have time to prepare for the next rustdoc JSON format version since we'd know which version will be in the next stable?
Are there any downsides we should consider? Because to me, that seems very worth doing — perhaps in addition to multi-version capability so we can support more than one stable at a time.
Are there any downsides we should consider?
The main thing to remember is its just as unstable as nightly.
From what I understand, the Linux kernel is using the RUSTC_BOOTSTRAP approach.
Because to me, that seems very worth doing — perhaps in addition to multi-version capability so we can support more than one stable at a time.
Yes, I see both routes being worth while.