Tracking issue: Checking cross-crate items

[obi1kenobi]

cargo-semver-checks currently only generates and analyzes a single crate's rustdoc JSON at a time. If that crate's public API exposes or relies on items from other crates, those foreign items are not present in the rustdoc JSON we get to see.

This can cause both false-positives (e.g. #609) and false-negatives (e.g. #629).

The purpose of this issue is to have a single place to link to when this conversation comes up, and to have a single location where interested folks can track progress.

The underlying technical reasons for the lack of cross-crate checking are the following:

• Rustdoc doesn't inline re-exported items across crates. This used to be the case, but was removed because it was causing lots of bugs and other kinds of unpleasantness.
• There's currently no reliable way to determine which dependency (including crate and exact version, to distinguish between multiple major versions) a cross-crate item came from. There has been interest in adding such a mechanism, though progress seems to have slowed recently: Add a new --orchestrator-id flag to rustc rust-lang/compiler-team#635
• After such a mechanism is added, there will still be probably 3-6 person-months of work needed on the cargo-semver-checks side: we'll need to analyze each rustdoc JSON to find 3rd party crates whose rustdoc JSON we also need, and recursively generate more rustdoc JSON until we've resolved all items in the public API we're scanning. Such a large investment of time would require finding a more permanent source of funding for the project — sponsoring me on GitHub is the way to do that. When I can cover rent with cargo-semver-checks, I'll be much more able to work on time-consuming improvements like this.

A note on resolver v1 vs v2: using cargo metadata implicitly uses resolver v1 (regardless of the resolver version selected by the crate), which in some cases may disagree on which features are enabled in downstream crates for crates that use resolver v2. When we analyze more broadly across the dependency graph, keep this in mind and make sure we get this right.