New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for crates that are compiler dependencies #27812

Open
alexcrichton opened this Issue Aug 13, 2015 · 15 comments

Comments

Projects
None yet
@alexcrichton
Member

alexcrichton commented Aug 13, 2015

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

This comment has been minimized.

Contributor

arielb1 commented Aug 13, 2015

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 comment has been minimized.

Member

alexcrichton commented Aug 13, 2015

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

This comment has been minimized.

Contributor

DemiMarie commented Mar 15, 2016

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

@tcr3dr

This comment has been minimized.

tcr3dr commented Jun 6, 2016

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

This comment has been minimized.

moises-silva commented Aug 5, 2016

Dear past @tcr3dr , Thanks from the future!

@rkruppe

This comment has been minimized.

Contributor

rkruppe commented Apr 30, 2017

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

This comment has been minimized.

Member

eddyb commented Apr 30, 2017

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

This comment has been minimized.

Kixunil commented May 29, 2017

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

This comment has been minimized.

Member

steveklabnik commented May 30, 2017

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

This comment has been minimized.

Kixunil commented May 30, 2017

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

This comment has been minimized.

andreycizov commented Jul 17, 2017

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

This comment has been minimized.

ishaniGupta27 commented Apr 27, 2018

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

This comment has been minimized.

Member

eddyb commented Apr 27, 2018

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

@ubsan

This comment has been minimized.

Contributor

ubsan commented Sep 3, 2018

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

This comment has been minimized.

Contributor

SimonSapin commented Sep 3, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment