Thanks to visit codestin.com
Credit goes to github.com

Skip to content

feat(rustdoc-json): Add optional support for rkyv (de)serialization#153283

Open
LukeMathWalker wants to merge 1 commit intorust-lang:mainfrom
LukeMathWalker:add-rkyv-support
Open

feat(rustdoc-json): Add optional support for rkyv (de)serialization#153283
LukeMathWalker wants to merge 1 commit intorust-lang:mainfrom
LukeMathWalker:add-rkyv-support

Conversation

@LukeMathWalker
Copy link
Contributor

Motivation

The JSON documents produced by rustdoc-json are big. More often than not, tools need to access a small fraction of that output—e.g. a couple of types from a transitive dependency, or a subset of the fields on a given rustdoc-json-types type.

Using a binary (de)serialization format and a cache helps to drive down the performance cost of deserialization: you invoke rustdoc-json to get the JSON output you need, re-serialize it using a more perfomant format as target (e.g. bincode or postcard) and thus amortize the cost of future queries that hit the persistent cache rather than rustdoc-json.
This is better, but still not great: the deserialization cost for crates like std still shows up prominently in flamegraphs.

An Alternative Approach: rkyv

rkyv provides a different opportunity: you avoid paying the deserialization cost upfront thanks to zero-copy deserialization.
You're often able to determine if you need a certain entry from the JSON document using the archived version of that type, thus incurring the full deserialization cost only for the subset of items you actually need (example).

The Change

This PR adds support for rkyv behind a feature flag (rkyv_0_8).
For most types, it's a straight-forward derive(rkyv::Archive, rkyv::Serialize, rkyv::Deserialize) annotation. For co-recursive types, we need to adjust the generated bounds, using the techniques from rkyv's JSON example.

I have added new round-trip tests to ensure rkyv works as expected.

r? @aDotInTheVoid

@rustbot
Copy link
Collaborator

rustbot commented Mar 2, 2026

rustdoc-json-types is a public (although nightly-only) API. If possible, consider changing src/librustdoc/json/conversions.rs; otherwise, make sure you bump the FORMAT_VERSION constant.

cc @CraftSpider, @aDotInTheVoid, @Enselic, @obi1kenobi

@rustbot rustbot added A-rustdoc-json Area: Rustdoc JSON backend S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Mar 2, 2026
@rustbot
Copy link
Collaborator

rustbot commented Mar 2, 2026

aDotInTheVoid is currently at their maximum review capacity.
They may take a while to respond.

@rust-log-analyzer

This comment has been minimized.

Copy link
Member

@aDotInTheVoid aDotInTheVoid left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes sense as a thing to add.

View changes since this review


#[cfg(feature = "rkyv_0_8")]
mod rkyv {
use std::fmt::Debug;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These tests don't run. When I applied

diff --git a/src/rustdoc-json-types/tests.rs b/src/rustdoc-json-types/tests.rs
index e878350e43b..258c22304c3 100644
--- a/src/rustdoc-json-types/tests.rs
+++ b/src/rustdoc-json-types/tests.rs
@@ -41,6 +41,11 @@ fn test_union_info_roundtrip() {

 #[cfg(feature = "rkyv_0_8")]
 mod rkyv {
+    #[test]
+    fn definenly_fails() {
+        panic!("at least the rkyv tests were ran");
+    }
+
     use std::fmt::Debug;

     use rkyv::Archive;

Running ./x test ./src/rustdoc-json-types/ still passed.

The fix (I think) is to enable this feature in bootsrap:

diff --git a/src/bootstrap/src/core/build_steps/test.rs b/src/bootstrap/src/core/build_steps/test.rs
index 88f10775333..ab1d2b8a24b 100644
--- a/src/bootstrap/src/core/build_steps/test.rs
+++ b/src/bootstrap/src/core/build_steps/test.rs
@@ -3302,7 +3302,7 @@ fn run(self, builder: &Builder<'_>) {
             builder.kind,
             "src/rustdoc-json-types",
             SourceType::InTree,
-            &[],
+            &["rkyv_0_8".to_owned()],
         );

         // FIXME: this looks very wrong, libtest doesn't accept `-C` arguments and the quotes are fishy.

(CC @jieyouxu, is this ok to do?)

#[cfg_attr(feature = "rkyv_0_8", derive(rkyv::Archive, rkyv::Serialize, rkyv::Deserialize))]
#[cfg_attr(feature = "rkyv_0_8", rkyv(derive(Debug)))]
#[cfg_attr(feature = "rkyv_0_8", rkyv(serialize_bounds(
__S: rkyv::ser::Writer + rkyv::ser::Allocator,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When are these needed? I'm a bit hesitant about the maintenence requirement, given that it seems a bit more onerous that just adding the same derives everywhere. Could you maybe at a comment (at the top of the file) explaining which rkyv bounds are needed where (or link to their docs on this).

/// to parse them, or otherwise depend on any implementation details.
#[derive(Clone, Copy, Debug, PartialEq, Eq, PartialOrd, Ord, Hash, Serialize, Deserialize)]
#[cfg_attr(feature = "rkyv_0_8", derive(rkyv::Archive, rkyv::Serialize, rkyv::Deserialize))]
#[cfg_attr(feature = "rkyv_0_8", rkyv(derive(Debug, PartialEq, Eq, PartialOrd, Ord, Hash)))]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does this have more rkyv(derives than the other types?

//! We expose a `rustc-hash` feature that is disabled by default. This feature switches the
//! [`std::collections::HashMap`] for [`rustc_hash::FxHashMap`] to improve the performance of said
//! `HashMap` in specific situations.
//!
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIT: Could you add a doc-comment about the rkyv_0_8 feature?

@aDotInTheVoid
Copy link
Member

@rustbot author

@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 3, 2026
@rustbot
Copy link
Collaborator

rustbot commented Mar 3, 2026

Reminder, once the PR becomes ready for a review, use @rustbot ready.

@rustbot rustbot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Mar 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-rustdoc-json Area: Rustdoc JSON backend S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants