Alert the user up-front when their dependency graph contains unstable code and they're building on stable or beta Rust

[bstrie]

It's no fun to start building a crate with a deep dependency graph only to be alerted that you've gotten the wrong version of Rust once you're 96 crates in (see https://twitter.com/peterhellberg/status/691025290617843712).

There are crates out there that use Cargo features to selectively gate parts of their API depending on whether the consumer is building on stable or nightly, so a naive scan for "#![feature" won't suffice (but could still serve as a decent first-approximation guess).

Ideally we'd want to be able to just kick off parallel parse jobs for all dependencies (we wouldn't even need any extra logic in Cargo, assuming that stable rustc bails on #![feature] during the parse phase), though with Cargo being a thin shell over issuing rustc commands manually we'd need to think about how best to do this. We'd also want to be able to cache the parse output to avoid lengthening build times in the general case (and I don't believe that incremental recompilation currently expects to cache the raw AST as a workproduct?).

Alternatively we could seek to leverage crates.io to communicate whether or not a crate builds on stable and relay this information to Cargo. This wouldn't be bulletproof given that Cargo can grab deps from places other than crates.io, but given crates.io's policy of allowing only crates.io subdependencies this would be guaranteed to suffice for users whose deps are all sourced from crates.io. Furthermore, such a feature has been desired for a long time on the frontend, to communicate to a user whether or not a given crate builds on stable or nightly (though to reiterate, this may be complicated by crates that offer both stable and unstable versions of their interfaces); is there an open issue for this yet?

This issue is ameliorated by the fact that we continue to stabilize features apace, so over time this will become less and less important. Still, as long as syntax extensions are unstable we're going to have a large chunk of people on nightly that could benefit from this, especially considering that this issue has implications for new users developing first impressions of our tooling.

[alexcrichton]

I personally feel that this represents a pretty significant investment in terms of work to do right where it's not a cost to normal users, and it's not necessarily worth just waiting to move to stable (which already has quite a large ecosystem).

At this time it doesn't seem that there's something simple yet-reliable to do, but if there were I certainly wouldn't mind taking a PR!

[durka]

@bstrie you said cargo should kick off parallel rustc jobs for each dep... how is that different from what it already does? It seems to me to make this a useful check the "builds on stable" badge has to be available without downloading the crate, i.e. a crates.io badge (I guess it wouldn't have to be actually visible on crates.io if we wanted to hide the information for some strange reason). It seems doubtful that crates.io will grow the infrastructure to try building all uploaded crates any time soon, but maybe we could trust crate authors and provide an opt-in checkbox for "yes, I target stable and it works"?

[carols10cents]

I think this is going to be covered by the feature added in rust-lang/crates.io#764 and #3627, which I swear I'm going to merge soon, so I'm going to close this :)