Skip to content

Tracking issue for crates that are compiler dependencies #27812

Open
@alexcrichton

Description

@alexcrichton
Member

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?

Activity

added
T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.
B-unstableBlocker: Implemented in the nightly compiler and unstable.
on Aug 13, 2015
arielb1

arielb1 commented on Aug 13, 2015

@arielb1
Contributor

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

alexcrichton commented on Aug 13, 2015

@alexcrichton
MemberAuthor

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

DemiMarie commented on Mar 15, 2016

@DemiMarie
Contributor

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

tcr3dr

tcr3dr commented on Jun 6, 2016

@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

moises-silva commented on Aug 5, 2016

@moises-silva

Dear past @tcr3dr , Thanks from the future!

hanna-kruppe

hanna-kruppe commented on Apr 30, 2017

@hanna-kruppe
Contributor

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

eddyb commented on Apr 30, 2017

@eddyb
Member

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

Kixunil commented on May 29, 2017

@Kixunil
Contributor

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?

45 remaining items

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    B-unstableBlocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCLibs-TrackedLibs issues that are tracked on the team's project board.S-tracking-perma-unstableStatus: The feature will stay unstable indefinitely.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @steveklabnik@alexcrichton@eddyb@SimonSapin@moises-silva

        Issue actions

          Tracking issue for crates that are compiler dependencies · Issue #27812 · rust-lang/rust