"stable" feature stopped compiling

[RalfJung]

With v0.3.20, compiletest with the "stable" feature seemingly stopped working:

error[E0658]: use of unstable library feature 'test' (see issue #27812)
  --> /home/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/compiletest_rs-0.3.20/src/lib.rs:23:1
   |
23 | extern crate libtest as test;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = help: add #![feature(test)] to the crate attributes to enable

Also see https://travis-ci.com/rust-lang/miri/jobs/186258530

[Manishearth]

As far as we could tell the stable feature didn't work anyway? If you look at the travis build history the stable builds are broken.

cc @gnzlbg

[RalfJung]

Miri used the stable feature until this night (when it broke), so it definitely worked.

[Manishearth]

Hm. cargo +stable build --features stable is broken on the previous version, though.

[Manishearth]

Anyway, @gnzlbg is going to update this with a stable libtest today, and stable will be the default soon for this crate

[RalfJung]

What can I say, rust-lang/miri#650 landed and CI was green with 0.3.19.

[dtolnay]

I noticed this too -- all my stable compiletest cron builds broke when updated from 0.3.19 to 0.3.20:

• https://travis-ci.org/serde-rs/serde/jobs/508749639
• https://travis-ci.org/serde-rs/json/jobs/508656488
• https://travis-ci.org/dtolnay/indoc/jobs/508665387
• https://travis-ci.org/dtolnay/ref-cast/jobs/508805923
• https://travis-ci.com/dtolnay/serde-repr/jobs/186213117
• https://travis-ci.org/dtolnay/tt-call/jobs/509066079

Locally, cargo +stable build --features stable fails at 64ecab2 but passes at its parent commit e2056b1. @Manishearth, beyond @gnzlbg's fixes I would like it if we could identify why we thought this build was already broken at the previous release so that we can patch up any remaining gaps in CI coverage for compiletest.

[Manishearth]

Yeah, once gnzlbg's fixes happen we can patch up CI to ensure it works too

[dtolnay]

Sounds good, thanks.

[dtolnay]

Ping -- please yank 0.3.20 if a fix is not imminent, as downstream builds are still failing.

[Manishearth]

Done.

[RalfJung]

I would like it if we could identify why we thought this build was already broken at the previous release

@Manishearth it would be great if you could say why you wrote this. The commit log looks very much like this crate was fine on stable until #162 landed.

[Manishearth]

Ah, sorry, that was basically because two of us independently couldn't figure out why libtest could be linked against on stable in the first place, and my local test didn't work.

The reason my local test didn't work was that my stable toolchain was broken (it had been broken for deliberate reasons to test something) and didn't have the rust libs in the right place so it gave exactly the error I'd expect given what the code did. I later realized this and fixed my toolchain and stuff worked again.

(The reason we were surprised this works on stable is that rustc is basically a bit weird when it comes to linking against the shipped libtest, which is allowed but you can't use anything)

[Manishearth]

Either way, now that we're doing the libtest stuff properly, there's a path forward for this crate to not need nightly anymore

[RalfJung]

I think the extern crate test here resolves to https://github.com/messense/rustc-test/blob/master/Cargo.toml, and that's why things can be used. But I am not sure.

[Manishearth]

That's not mentioned in the Cargo.toml at all.

Rustc ships with a libtest, that's what's being pulled in.

[RalfJung]

That's not mentioned in the Cargo.toml at all.

It is:

tester = { version = "0.5", optional = true }

In fact, this is pulled in exactly by the "stable" flag, which is why I think this is how things can work at all on stable:

stable = ["norustc", "tester"]

[Manishearth]

That should not work with extern crate test though, that should work with extern crate tester

[RalfJung]

Yeah I thought so too, but there is no such line anywhere. Also notice that the Cargo.toml I linked above says

[lib]
name = "test"

Won't that change the name through which the crate can get imported?

[Manishearth]

I'm surprised you can do that.

[Manishearth]

This explains at least one of the issues we had when trying to get the new libtest stuff to work :)

[Manishearth]

rust-lang/cargo#6827

[RalfJung]

I guess that explains the prior confusion then. :)

Where can we track the reverting of the libtest change that you mentioned?

[Manishearth]

rust-lang/rust#59766 , it's done already. I'm opening a rustup PR now.

[laumann]

@RalfJung Can I close this as being outdated?

[RalfJung]

Yeah the stable feature is working again. :) Thanks!