Re-exports of items from own crate cannot be semver-checked

[obi1kenobi]

Unfortunately, rustdoc JSON output does not seem to output re-export information in paths, so we don't seem to be able to get information on re-exports which we can query for semver issues.

Upstream tracking issue: rust-lang/rust#93522

[obi1kenobi]

Other related issues worth tracking:
rust-lang/rust#94336
rust-lang/rust#94338
rust-lang/rust#88758

[obi1kenobi]

Mostly resolved by tracking import items directly and reconstructing visibility rules and paths. Glob imports are still not supported, tracked by #34.

[mqudsi]

I'm not sure if this is resolved (or if I'm misunderstanding your original issue and I need to file this as something else).

If a crate re-exports a type or trait from a dependency as part of its public api and that re-exported type suffers from semver-incompatible changes, cargo-semver-checks currently still reports the release as passing. (no glob import involved)

I can provide a (real world) example if need be.

[obi1kenobi]

Hi! This issue was meant for re-exports that stay within one's own crate, and I've renamed it as such — thanks for pointing out the confusion.

What you're describing is definitely worth opening a new issue for. cargo-semver-checks currently makes no effort to scan anything coming from outside the one crate it's looking at at any given time. But this sounds like a worthwhile feature and I'd appreciate it if you could open an "enhancement" issue and include the real-world example you have found — it would help a lot!