Open
Description
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?
Metadata
Metadata
Assignees
Labels
Blocker: Implemented in the nightly compiler and unstable.Category: An issue tracking the progress of sth. like the implementation of an RFCLibs issues that are tracked on the team's project board.Status: The feature will stay unstable indefinitely.Relevant to the library API team, which will review and decide on the PR/issue.
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
arielb1 commentedon 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 commentedon Aug 13, 2015
This shouldn't compile on stable Rust:
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 commentedon Mar 15, 2016
What about using
-fvisibility=hidden
(or Rust's analog) and friends to solve the problem?tcr3dr commentedon 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:The fix is to add
log = "0.4"
to your Cargo.toml.moises-silva commentedon Aug 5, 2016
Dear past @tcr3dr , Thanks from the future!
hanna-kruppe commentedon 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 commentedon 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 commentedon May 29, 2017
Using
extern crate test;
points me to this issue. I need it to useBencher
(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