Description
@aDotInTheVoid I'm running into a serious issue making
cargo-semver-checks
support this format. I'd vote for reverting this change while we look for a better alternative — possibly by reworking what path is inpaths
.All this information is available in the
paths
field, and there it's in a more usable form, as it also includes the defining crate.This turns out to not be true in practice. The
paths
field includes the originally-defined path of the item, which is often private and not accessible. For example:
- Where
Path::name
previously containedIterator
(accessible via the prelude), thepaths
lookup producescore::iter::traits::iterator::Iterator
which is private.- Where
Path::name
previously containedstd::str::SplitAsciiWhitespace
, thepaths
lookup producescore::str::iter::SplitAsciiWhitespace
which is private.
etc.This is making
cargo-semver-checks
unable to properly print types, function signatures, trait bounds, etc. and effectively disables a bunch of lints.In theory, we could run c-s-c's importable paths analysis to derive a valid, publicly-importable path for the item instead of using the
paths
field. In practice, this is blocked in two ways:
- It requires cross-crate analysis, since most such items are in
std/core/alloc
etc. This is a goal, but as we've already chatted, it's many months out and blocked on rustc functionality etc.- Even if we had cross-crate analysis, it requires the ability to either download or generate rustdoc JSON for
std/core/alloc
. I don't know of a way to generate it client-side, and AFAIK we can download their rustdoc JSON for nightly Rust only. This would break c-s-c's ability to support multiple stable Rust versions.
Originally posted by @obi1kenobi in #134880 (comment)