Tracking issue for crates that are compiler dependencies

[alexcrichton]

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?

[eddyb]

@ishaniGupta27 #[bench] is still unstable, see #29553.

[strega-nil]

Could we please make is_xid_continue, and is_xid_start stable? They're useful checks that you have to download a 0.1 crate in order to get (with, currently, 4.5 million downloads)

Edit: also, this annoying thing happens when you try to use it:

warning: a method with this name may be added to the standard library in the future
  --> src\parser\lexer.rs:38:31
   |
38 |       Some((start, ch)) if ch.is_xid_start() => {
   |                               ^^^^^^^^^^^^
   |
   = note: #[warn(unstable_name_collisions)] on by default
   = warning: once this method is added to the standard library, the ambiguity may cause an error or change in behavior!
   = note: for more information, see issue #48919 <https://github.com/rust-lang/rust/issues/48919>
   = help: call with fully qualified syntax `unicode_xid::UnicodeXID::is_xid_start(...)` to keep using the current method
   = note: add #![feature(rustc_private)] to the crate attributes to enable `std::char::methods::<impl char>::is_xid_start`

[SimonSapin]

Why is the 0.1 version number significant? It only means that the crate hasn’t changed much since it was extracted from the standard library.

Regarding the warning, we should probably replace the trait in that crate with a pair of free functions.

[banool]

A lot of people probably end up here because the compiler points you here when you see the rustc_private error. For people who know nothing about the compiler and are wondering why you're seeing this error, it might be worth trying to get some traction on this issue: #50373.

[dd-pardal]

For anyone here because of copying the example lib.rs file from The Rust and WebAssembly Tutorial: This can be fixed by adding cfg-if = "0.1.10" to the [dependencies] table in Cargo.toml.

[Mark-Simulacrum]

As of latest stable (1.40), we no longer ship the rustc-dev component by default, and as of #67469, the same is true for nightly. We could now plausibly stop shipping the rustc-dev component onto stable and beta, which would effectively make all compiler-internal crates unstable (and unavailable by default).

However, I expect we'll still want to keep the rustc_private feature around as ungating the compiler libraries would make it a bit too easy to use them accidentally if you happen to have the rustc-dev component installed.

At the very least though hopefully from now on users won't be confused by the "unstable library feature rustc_private" message on stable anymore!

On 1.40, this is the error you get:

error[E0463]: can't find crate for `log`
 --> t.rs:1:1
  |
1 | extern crate log;
  | ^^^^^^^^^^^^^^^^^ can't find crate

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.

whereas previously you got:

error[E0658]: use of unstable library feature 'rustc_private': this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via `Cargo.toml` instead?
 --> t.rs:1:1
  |
1 | extern crate log;
  | ^^^^^^^^^^^^^^^^^
  |
  = note: for more information, see https://github.com/rust-lang/rust/issues/27812

[Kixunil]

Does this mean suppressing optimizations used for benchmarking will stop working?

[Mark-Simulacrum]

I think your comment has nothing to do with this issue? The unstable test crate is still shipped, it was never gated behind the rustc_private flag.

[Kixunil]

Ah, OK, I was confused. Thanks for clarifying!

[Mercanuis]

This is occuring again, I am getting the following error , using either raze or crate_universe

M1 Mac

error[E0658]: use of unstable library feature 'rustc_private': this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via `Cargo.toml` instead?
  --> external/crate_universe_dependencies__atty__0_2_14/src/lib.rs:21:1
   |
21 | extern crate libc;
   | ^^^^^^^^^^^^^^^^^^
   |
   = note: see issue #27812 <https://github.com/rust-lang/rust/issues/27812> for more information

The deps in question depend on what is built first but ran into

• atty
• gen_random