-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Remove internal liblog #40347
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Remove internal liblog #40347
Conversation
r? @arielb1 (rust_highfive has picked a reviewer for you, use r? to override) |
r? @brson Note that this is the first crates.io crate to be included in the compiler itself, but I believe that everything is ironed out! Also note that we have a test if a crate is used and the annotations above are forgotten. We also have license checking for crates.io deps to get errors by default if were working with unusual licenses. |
I seem to recall that the behavior of |
@rkruppe for the compiler I've now enabled the |
(good catch!) |
@bors r+ |
📌 Commit 5f10bb5 has been approved by |
@bors: r- this breaks a number of crates |
How did you determine this? |
Heh via wizardry :) (the travis logs also indicate this) I have suspicions for what's going on here and how to fix it, I don't have time to act on them just yet though. |
☔ The latest upstream changes (presumably #40432) made this pull request unmergeable. Please resolve the merge conflicts. |
@bors: r=brson |
📌 Commit a4bd5e9 has been approved by |
Remove internal liblog This commit deletes the internal liblog in favor of the implementation that lives on crates.io. Similarly it's also setting a convention for adding crates to the compiler. The main restriction right now is that we want compiler implementation details to be unreachable from normal Rust code (e.g. requires a feature), and by default everything in the sysroot is reachable via `extern crate`. The proposal here is to require that crates pulled in have these lines in their `src/lib.rs`: #![cfg_attr(rustbuild, feature(staged_api, rustc_private))] #![cfg_attr(rustbuild, unstable(feature = "rustc_private", issue = "27812"))] This'll mean that by default they're not using these attributes but when compiled as part of the compiler they do a few things: * Mark themselves as entirely unstable via the `staged_api` feature and the `#![unstable]` attribute. * Allow usage of other unstable crates via `feature(rustc_private)` which is required if the crate relies on any other crates to compile (other than std).
It looks like Travis hit an ICE. Is that related to these changes? |
No idea how, but my guess is yes :( @bors: r- |
📌 Commit e4af5fd has been approved by |
Remove internal liblog This commit deletes the internal liblog in favor of the implementation that lives on crates.io. Similarly it's also setting a convention for adding crates to the compiler. The main restriction right now is that we want compiler implementation details to be unreachable from normal Rust code (e.g. requires a feature), and by default everything in the sysroot is reachable via `extern crate`. The proposal here is to require that crates pulled in have these lines in their `src/lib.rs`: #![cfg_attr(rustbuild, feature(staged_api, rustc_private))] #![cfg_attr(rustbuild, unstable(feature = "rustc_private", issue = "27812"))] This'll mean that by default they're not using these attributes but when compiled as part of the compiler they do a few things: * Mark themselves as entirely unstable via the `staged_api` feature and the `#![unstable]` attribute. * Allow usage of other unstable crates via `feature(rustc_private)` which is required if the crate relies on any other crates to compile (other than std).
@bors: r=brson |
📌 Commit e341d60 has been approved by |
⌛ Testing commit e341d60 with merge 4509a6e... |
💔 Test failed - status-travis |
… On Fri, Mar 24, 2017 at 9:10 AM, bors ***@***.***> wrote:
💔 Test failed - status-travis
<https://travis-ci.org/rust-lang/rust/builds/214641032>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#40347 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAD95COiO5fGF0MSF_BVZlZZ3GDPGxMrks5ro87EgaJpZM4MWXFU>
.
|
Remove internal liblog This commit deletes the internal liblog in favor of the implementation that lives on crates.io. Similarly it's also setting a convention for adding crates to the compiler. The main restriction right now is that we want compiler implementation details to be unreachable from normal Rust code (e.g. requires a feature), and by default everything in the sysroot is reachable via `extern crate`. The proposal here is to require that crates pulled in have these lines in their `src/lib.rs`: #![cfg_attr(rustbuild, feature(staged_api, rustc_private))] #![cfg_attr(rustbuild, unstable(feature = "rustc_private", issue = "27812"))] This'll mean that by default they're not using these attributes but when compiled as part of the compiler they do a few things: * Mark themselves as entirely unstable via the `staged_api` feature and the `#![unstable]` attribute. * Allow usage of other unstable crates via `feature(rustc_private)` which is required if the crate relies on any other crates to compile (other than std).
⌛ Testing commit e341d60 with merge 1ff1f1d... |
💔 Test failed - status-travis |
⌛ Testing commit e341d60 with merge 6b90ac4... |
💔 Test failed - status-travis |
⌛ Testing commit e341d60 with merge e092448... |
💔 Test failed - status-travis |
⌛ Testing commit e341d60 with merge 7dd4e2d... |
Remove internal liblog This commit deletes the internal liblog in favor of the implementation that lives on crates.io. Similarly it's also setting a convention for adding crates to the compiler. The main restriction right now is that we want compiler implementation details to be unreachable from normal Rust code (e.g. requires a feature), and by default everything in the sysroot is reachable via `extern crate`. The proposal here is to require that crates pulled in have these lines in their `src/lib.rs`: #![cfg_attr(rustbuild, feature(staged_api, rustc_private))] #![cfg_attr(rustbuild, unstable(feature = "rustc_private", issue = "27812"))] This'll mean that by default they're not using these attributes but when compiled as part of the compiler they do a few things: * Mark themselves as entirely unstable via the `staged_api` feature and the `#![unstable]` attribute. * Allow usage of other unstable crates via `feature(rustc_private)` which is required if the crate relies on any other crates to compile (other than std).
☀️ Test successful - status-appveyor, status-travis |
This commit deletes the internal liblog in favor of the implementation that
lives on crates.io. Similarly it's also setting a convention for adding crates
to the compiler. The main restriction right now is that we want compiler
implementation details to be unreachable from normal Rust code (e.g. requires a
feature), and by default everything in the sysroot is reachable via
extern crate
.The proposal here is to require that crates pulled in have these lines in their
src/lib.rs
:This'll mean that by default they're not using these attributes but when
compiled as part of the compiler they do a few things:
staged_api
feature and the#![unstable]
attribute.feature(rustc_private)
which isrequired if the crate relies on any other crates to compile (other than std).