Tracking issue for crates that are compiler dependencies

[alexcrichton]

View all comments

This is a tracking issue for the unstable rustc_private feature of the standard distribution. It's pretty unfortunate that we have to explicitly prevent everyone from linking to compiler internals via stability attributes, it'd be better if we just didn't ship them at all perhaps.

Is there a better solution? Must we rely on instability forever?

[arielb1]

Why do we need the stability attributes there anyway? librustc is as much a part of the stable API as the symbol names (which can be accessed via dlopen).

[alexcrichton]

This shouldn't compile on stable Rust:

extern crate rustc;
fn main() {}

Currently we use stability attributes to achieve this goal. I think it's a bit of a stretch to say we've stabilized librustc because we've shipped a binary for it, so I don't consider the fact that you can dlopen it to be any sort of commitment to stability.

[DemiMarie]

What about using -fvisibility=hidden (or Rust's analog) and friends to solve the problem?

[tcr3dr]

For future travelers: if you mistakenly #[macro_use] extern crate log; but don't require log in your Cargo.toml, you may trigger this bug:

src/lib.rs:4:14: 4:31 error: use of unstable library feature 'rustc_private': use the crates.io `log` library instead (see issue #27812)
src/lib.rs:4 #[macro_use] extern crate log;

The fix is to add log = "0.4" to your Cargo.toml.

[moises-silva]

Dear past @tcr3dr , Thanks from the future!

[hanna-kruppe]

So I've been thinking about this issue, because it blocks a PR of mine. @eddyb suggested a -Z flag. This does sound good, except we'd want this mechanism perma-unstable and we don't even fully enforce stability of compiler flags yet. So how about this: Add -Z rustc-private-hack (straw name, but it's intentionally unappealing) which is equivalent to adding #![unstable(feature = "rustc_private", issue = "0")] to all crates that don't already have a stability attribute. rustbuild would set it, and other people would hopefully be discouraged from using it by the ugly name and the very limited applicability.

However, I have no idea how easy or hard it would be to implement this.

[eddyb]

I meant to look into it, and unless something else comes up, I'll try tomorrow.
IMO it should be -Z force-unstable=rustc_private.

[Kixunil]

Using extern crate test; points me to this issue. I need it to use Bencher (specifically, to force compiler into computing some value).

Is there any work-around for this?

What's blocking stabilization of test specifically? What can be done about it?

[steveklabnik]

that's closer to #29553, really. This one is related.

(specifically, to force compiler into computing some value).

You're trying to inhibit optimizations somewhere?

Is there any work-around for this?

https://crates.io/crates/bencher would be, except it's missing the one thing you need.

What's blocking stabilization of test specifically? What can be done about it?

My perspective, though I'm not on the appropriate team so don't take this as gospel. Nobody has put in the needed work to get it to stable; that is, it's largely considered an internals-only thing, and hasn't been evaluated properly for stabilization.

[Kixunil]

You're trying to inhibit optimizations somewhere?

Yes, specifically in fast_fmt bench. The string must always be produced for benchmark to make sense.

[andreycizov]

I believe there's a point in removing this from the old book published on the website, as the second one is mentioned as "under construction", and you always end up in the first one over here: https://doc.rust-lang.org/1.12.1/book/benchmark-tests.html

Can be quite distracting for beginners.

[ishaniGupta27]

use of unstable library feature 'test' . I am getting this issue when I am trying to use it for benchmarking. Any workaround for this?