I might have not been clear enough. All of the following only applies to nightly, but Rust 2018 is a nightly-only thing right now.
Updating a crate to become a Rust 2018 crate is a non-breaking API change, so any nightly crate can start using the feature and do a new release that increases the minor semver version.
When that happens, all crates that are currently properly targeting the last release of that crate, suddenly start linking against a Rust 2018 crate. This typically happens automatically in CI unless people hardcode dependencies.
This is already happening in nightly as more and more nightly crates start using the 2018 preview feature. Every crate that is still not using the 2018 feature but is using dependencies that do is testing this on CI already.
The problem with enabling Rust 2018 in libc or similar crates is that they support stable users, so we would need to add an
unstable feature (that almost nobody would use) and enable Rust 2018 behind it. In the particular case of
libc, it already has such a feature to enable things like
repr(packed(N)) support, but while some crates are using it, most crates are not.
So I don’t fully understand the concern that things are not being tested. This is being tested on nightly, which is the best thing we can do right now.
If the concern is that we are not testing Rust 2015 / 2018 compatibility on stable Rust, then that’s a real issue, but we are testing that on nightly, and we will test that 6 weeks during beta, so I just hope that everything will just work on stable if it worked on both nightly and beta (and if it doesn’t, that the issues are minor enough that can be fixed in a point release). The concern that people are not properly testing beta on CI is also a real concern, but that’s not really news and applies to all Rust features (and Rust 2018 is just another rust feature from the compiler point of view).