-
-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nightly 2022-09-06 fails, needs rustdoc-types
v0.16.0 upgrade
#138
Comments
Yep, rust-lang/rust#101462 was merged yesterday which changed the rustdoc JSON format. Todays nightly is the first nightly with the new format. This was also detected by the CI in this project which runs nightly for exactly this purpose: https://github.com/Enselic/cargo-public-api/runs/8220773135?check_suite_focus=true This is now Warning: Probably tomorrows nightly will have yet another incompatible change: rust-lang/rust#101521 (comment) @Emilgardis You wanted to take care of doing the rustdoc JSON format bump next time (read: tomorrow), I think? Let me know if you would like me to do it, otherwise I will happily leave it up to you. As a remark, we are not 100% independently able to adapt to rustdoc JSON format changes, we also depend on rustdoc_types crate to be updated: aDotInTheVoid/rustdoc-types@338e734 We could use our own fork, but I don't want to split the small rustdoc JSON community that has formed :) @repi I agree it will be nice once rustdoc JSON hits stable :) |
go ahead and do it @Enselic :) |
thanks! and yup we had to pin to |
Gah, sorry for all the breakage recently. If you want nicer errors, And in regards to stability, even once all outstanding bugs are fixed, and we're totally satisfied with the format, docs, tests etc, I'm still not sure if we can be stable, while allowing adding new language constructs. I've wrote about this on zulip, and would love input on this. Finally, |
Personally I don't mind the breakage much; this was what I signed up for when deciding to depend on nightly :) For now, I think freely evolving the rustdoc JSON format is more important than keeping it stable. Long term it would be nice with some form of stability, but we'll get there when we get there. (I will repeat this on Zulip later so we can continue discussing there)
cargo-public-api also has this property actually. So if the generated rustdoc JSON is simple enough to not contain the incompatible change (e.g. if the incompatible change affected enums, but the crate does not contain enums), then cargo public-api will not error out either. cargo-public-api also only errors if there is a deserialization error;
I have a proposal: Why don't we automate This repo has more or less fully automated Note the Owners of https://crates.io/crates/cargo-public-api includes I could help you set this up if you are interested. Reusing https://github.com/EnselicCICD would be the simplest by far, but if you want to set up your own org (mine is at http://github.com/cargo-public-api), that's of course perfectly fine. I think it would be great to have automated Some further reading: https://doc.rust-lang.org/cargo/reference/publishing.html
|
Sorry I wasn't clear. cargo-semver-checks way still succeeds/fails in all the same cases, but the advantage is to create a relevent error that points to version mismatch, rather than some unactionable serde error.
This sounds like a good idea. I don't think I want in to completely automaticly publish a new version every time rust-lang/rust/src/rustdoc-json-types changes, but doing some automation to generate a Issue or PR on change would be fastastic, I've filed aDotInTheVoid/rustdoc-types#18 to track this |
I agree it is a clever trick, but I actually prefer to shield my users from For reference, here is the error users see if their nightly is too new for
Edit: I guess I could actually make the error message less speculative by also checking
OK! I currently have a bit too much to do, but once I get time over I will be happy to assist. |
Otherwise fails in one of our crates on:
looks like a pretty small upgrade of the types.
stabilization of rustdoc json output can't come soon enough! :)
The text was updated successfully, but these errors were encountered: