Manifest checks

[epage]

The API extends past the rust code to the manifest

Possible checks include

• Explicit feature removed (major breaking)
• Implicit feature (optional dependency) removed (informative)
  • This is separate because pre-1.60's namespaced features, crates couldn't hide these
• Implicit feature added via removing dep: reference to optional dependency (informative)
• Explicit feature no longer implies another explicit feature (major breaking)
• Feature no longer implies an implicit feature (informative)

[obi1kenobi]

The primary challenge in this issue is coming up with a good design with respect to the experience we offer users.

Two open questions we should consider before embarking toward implementing this feature:

• I haven't looked at the sparse index design. Can we always get a manifest file even with a sparse index? Or would we need to run cargo metadata somehow instead?
• Currently we allow users to specify their own rustdoc JSON instead of relying on c-s-c to generate it. In that case, are manifest checks disabled? Or do we allow or require users to also specify a manifest file?

[epage]

I haven't looked at the sparse index design. Can we always get a manifest file even with a sparse index? Or would we need to run cargo metadata somehow instead?

You can't get the full manifest from the index (sparse or git). You could use cargo metadata in the temp projects that are created.

Currently we allow users to specify their own rustdoc JSON instead of relying on c-s-c to generate it. In that case, are manifest checks disabled? Or do we allow or require users to also specify a manifest file?

What are the use cases for this feature?

I wonder if the approach to take is to split up the library logic so someone can make a custom tool using only the rustdoc side of things while the high level command only works on packages and not on rustdoc json.

[obi1kenobi]

Yeah, maybe the answer is that we remove that feature. It's relatively rarely used, generally when one's CI already builds rustdoc JSON (for either current or baseline) in a separate step and wants to avoid a (potentially expensive) rebuild inside c-s-c. For context, today each rustdoc JSON build takes ~15x as long as running all the checks combined — and if the baseline JSON isn't cached, then we do two rustdoc JSON builds.

Or maybe we change this feature to expect a "bundle" file of some sort instead of a rustdoc JSON file. This bundle could hold the rustdoc JSON + manifest, and in the future when we do cross-crate analysis it could also hold re-exported dependency crates' rustdoc JSON files as well. Our baseline caching logic will have to be updated to also cache manifest info anyway, so perhaps the bundling logic gets reused from there.

We have options, this is surmountable.