Skip to content
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

Enable using libraries from crates.io without polluting them with stability attributes #41576

Closed
hanna-kruppe opened this issue Apr 27, 2017 · 2 comments

Comments

@hanna-kruppe
Copy link
Contributor

hanna-kruppe commented Apr 27, 2017

All (transitive) dependencies of the compiler and standard library wind up in the sysroot, and could therefore be used by anyone. We don't want to guarantee the existence, much less version/API of any crates except (currently) std, core, and proc_macro. Therefore all other crates must be marked as unstable, often with the feature name rustc_private. This also applies to crates from crates.io, but this currently means a couple of lines need to be copied into every such library to make them unstable if and only if they're being used as part of rustc. This is very ugly, and becomes a greater hurdle as we start reusing more third party libraries in rustc (since all affected crates need to be updated and release a new version, and again, this affects all transitive dependencies). We should find a way to not require this from crates.io libraries.

@eddyb mentioned the possibility of (IIUC) a -Z flag that applies a stability attribute to all crates that don't have one already. We could then pass this flag to all rustc invocations done while building rust, to implicitly make all our third-party dependencies rustc_private without modifying their source code.

cc @alexcrichton

@eddyb
Copy link
Member

eddyb commented Apr 27, 2017

This is a dupe of #27812.

@hanna-kruppe
Copy link
Contributor Author

Oops!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants