Track stability of path components

[brson]

The current stability check only checks a few uses: functions and methods. There is much more needed for the coverage to be complete. In particular, every path contains multiple components which should all be checked. Simply checking paths would improve the accuracy of the analysis greatly.

This requires modifying resolve to record the def_id's of path components, not just the entire path.

cc @aturon

[aturon]

cc #8962

[aturon]

cc #8967 as well.

We will also need to think carefully about the user experience for the lint for mostly-stable libraries. We may want opt-out at the crate level, or a way of coalescing warnings.

[lifthrasiir]

Nominating for 1.0. This is an important feature that possibly affects several libraries over the course of stabilization after 1.0 (I've already hit this twice with rust-encoding, see above). Also note that this doesn't have a simple workaround with an exception of function.

[pnkfelix]

P-high, not 1.0.

(This is highly desired, but it is not going to block a release.)

[brson]

Renominating because the ability to correctly detect the stability level of user code has a high impact on the guarantees we can provide.

[pnkfelix]

Assigning 1.0 milestone (it is considered polish, rather than a deep backwards compat issue).

[aturon]

@alexcrichton did your patch address this? For some reason it seemed it would be harder, but I don't really know.

[alexcrichton]

Unfortunately no, my patch didn't address this. For any path we still only track the stability of the last component.