libtest on stable Rust

[gnzlbg]

This PR makes libtest work on stable Rust by default. The stable and beta release channels are now tested on CI, and the crate was migrated to use the stable termcolor crate per the recommendation in #2 .

This PR adds:

• an unstable cargo feature that is disabled by default and can be optionally enabled to allow libtest to make use of some nightly-only features.

• the compiletest-rs crate as an integration test (cc @Manishearth ). Note: this test fails for now because the compiletest-rs needs to be updated to libtest 0.0.2 for it to work, which hasn't happened yet. It is therefore allowed to fail.

[gnzlbg]

cc @alexcrichton all CI is suspiciously green on first try 😆

The new build jobs on Travis and Azure appear to be testing the right Rust channels. Once this is merged I'll release 0.0.2 and get compiletest to use it and check that everything works fine, and once that is the case I'll update the libtest version in rust-lang/rust.

[gnzlbg]

Can you also udo a smoke test using [patch] to build this in upstream rust-lang/rust? Just to make sure that it builds at least through the first stage. (actually this may be reasonable to add to CI as it's in theory "guaranteed to work

I think I will try to set this up on CI before merging with rust upstream, but I feel its more important to unbrean clippy in the immediate future.

[gnzlbg]

So I've ran into a couple of problems while updating upstream that go beyond cosmetic changes:

• one is a cyclic dependency between test and libtest (because libtest needs test for black_box). I've opened a PR to move black_box to core::hint which would resolve this (we could remove the dependency on test by just using the feature(asm) in the mean time).

• there seems to be some problem unifying the libc and termcolor dependencies when building rustc. I get this for stage0:

error: cannot satisfy dependencies so `libc` only shows up once      ] 115/134: rustc                                          
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `termcolor` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: aborting due to 2 previous errors

error: Could not compile `rustc`.

I am not sure how to fix that @alexcrichton, but we can always fix that later and when that's done release 0.0.3 of libtest and update rust-lang/rust. Right now, clippy, miri, and other crates are broken without what this PR fixes.

[alexcrichton]

I think it'd probably be best to decouple whatever clippy/miri/others need from this PR? I don't know what's going on with the libc/termcolor "showing up once" problem, but it's something I feared would happen and is why it was never previously pursued to remove the libterm dependency.

I don't currently have the time to dig in and debug, so if fixes need to go in otherwise it may be best to get those first.

[Manishearth]

Can we speed up merging this? Clippy CI is broken, and this affects clippy releases in nightly.

[Manishearth]

Either that or undo the changes to libtest in rustc until we have a better overall story for this here.

[XAMPPRocky]

@gnzlbg Are you still planning on working on this?

[crlf0710]

@XAMPPRocky I believe this work is blocked. Let me try to summarize this:

1. Since libtest is meant to be compiled into user-built test executable, it needs a terminal color outputting crate, or the user won't have any colors.
2. The original libtest in tree is using libterm in tree, which is in unstable state.
3. In #2 it is adopted to switch to termcolor, after which we found out that it's not ready for shipping as sysroot crate, because of dependencies on winapi.
4. For crates to ship as sysroot crate, special treatments are needed.
5. This special treatment needs a higher MSRV, while winapi 0.3 wants to be compatible with rust 1.6. So this is only possible after we've got a winapi 0.4. See this PR. Blocked here
6. Another approach of going is to extract libterm as a separate crate. But so far no one wants to maintain it this way (yet). (libterm is inferior in functionality, but without dependencies.) Limbo here
7. Another approach of going is create a dependency-free version of termcolor. Actually i've hacked a forked version here. However it might be a lot of maintenance burden, so i've not sure this approach is really worth taking. Limbo here

[XAMPPRocky]

@crlf0710 Thank you for summarising and clarifying the current state of this work!