The “use of unstable library feature 'rustc_private'” error is very repetitive #44953

jakubadamw · 2017-10-01T06:28:39Z

rustc 1.22.0-nightly (0e6f4cf51 2017-09-27)

Compiling this:

#[macro_use] extern crate log;

pub fn main() {
    info!("This is a log message.");
}

while not including log as a dependency in Cargo.toml, produces the following output:

error: use of unstable library feature 'rustc_private': this crate is being loaded from the sysroot, and unstable location; did you mean to load this crate from crates.io via `Cargo.toml` instead? (see issue #27812)
 --> main.rs:1:14
  |
1 | #[macro_use] extern crate log;
  |              ^^^^^^^^^^^^^^^^^
  |
  = help: add #![feature(rustc_private)] to the crate attributes to enable

error: use of unstable library feature 'rustc_private': this crate is being loaded from the sysroot, and unstable location; did you mean to load this crate from crates.io via `Cargo.toml` instead? (see issue #27812)
 --> main.rs:4:2
  |
4 |  info!("This is a log message.");
  |  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = help: add #![feature(rustc_private)] to the crate attributes to enable
  = note: this error originates in a macro outside of the current crate

error: use of unstable library feature 'rustc_private': this crate is being loaded from the sysroot, and unstable location; did you mean to load this crate from crates.io via `Cargo.toml` instead? (see issue #27812)
 --> main.rs:4:2
  |
4 |  info!("This is a log message.");
  |  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = help: add #![feature(rustc_private)] to the crate attributes to enable
  = note: this error originates in a macro outside of the current crate

error: use of unstable library feature 'rustc_private': this crate is being loaded from the sysroot, and unstable location; did you mean to load this crate from crates.io via `Cargo.toml` instead? (see issue #27812)
 --> main.rs:4:2
  |
4 |  info!("This is a log message.");
  |  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = help: add #![feature(rustc_private)] to the crate attributes to enable
  = note: this error originates in a macro outside of the current crate

error: use of unstable library feature 'rustc_private': this crate is being loaded from the sysroot, and unstable location; did you mean to load this crate from crates.io via `Cargo.toml` instead? (see issue #27812)
 --> main.rs:4:2
  |
4 |  info!("This is a log message.");
  |  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = help: add #![feature(rustc_private)] to the crate attributes to enable
  = note: this error originates in a macro outside of the current crate

error: use of unstable library feature 'rustc_private': this crate is being loaded from the sysroot, and unstable location; did you mean to load this crate from crates.io via `Cargo.toml` instead? (see issue #27812)
 --> main.rs:4:2
  |
4 |  info!("This is a log message.");
  |  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = help: add #![feature(rustc_private)] to the crate attributes to enable
  = note: this error originates in a macro outside of the current crate

error: use of unstable library feature 'rustc_private': this crate is being loaded from the sysroot, and unstable location; did you mean to load this crate from crates.io via `Cargo.toml` instead? (see issue #27812)
 --> main.rs:4:2
  |
4 |  info!("This is a log message.");
  |  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = help: add #![feature(rustc_private)] to the crate attributes to enable
  = note: this error originates in a macro outside of the current crate

error: use of unstable library feature 'rustc_private': this crate is being loaded from the sysroot, and unstable location; did you mean to load this crate from crates.io via `Cargo.toml` instead? (see issue #27812)
 --> main.rs:4:2
  |
4 |  info!("This is a log message.");
  |  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = help: add #![feature(rustc_private)] to the crate attributes to enable
  = note: this error originates in a macro outside of the current crate

error: use of unstable library feature 'rustc_private': this crate is being loaded from the sysroot, and unstable location; did you mean to load this crate from crates.io via `Cargo.toml` instead? (see issue #27812)
 --> main.rs:4:2
  |
4 |  info!("This is a log message.");
  |  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = help: add #![feature(rustc_private)] to the crate attributes to enable
  = note: this error originates in a macro outside of the current crate

error: use of unstable library feature 'rustc_private': this crate is being loaded from the sysroot, and unstable location; did you mean to load this crate from crates.io via `Cargo.toml` instead? (see issue #27812)
 --> main.rs:4:2
  |
4 |  info!("This is a log message.");
  |  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = help: add #![feature(rustc_private)] to the crate attributes to enable
  = note: this error originates in a macro outside of the current crate

error: aborting due to 10 previous errors

The text was updated successfully, but these errors were encountered:

estebank · 2017-10-02T20:48:48Z

Mentoring instructions

Modify leveled_feature_err to accept an extra flag stating wether the help should be outputted or not (it's already checking wether the current compiler is nightly) so that TyCtxt::stability can keep track of wether a diagnostic of this type has already been emitted, and if it has, the help isn't shown.

zackmdavis · 2017-10-20T06:59:27Z

so that TyCtxt::stability can keep track of wether a diagnostic of this type has already been emitted

But TyCxt has access to the Session, which means we should be able to use the existing one_time_diagnostics field (if we slightly generalize it to take an Option<LintId> rather than a LintId to accomodate non-lint errors like the matter at hand).

However, the reported code isn't reproducing the issue for me with a stage 1 compiler, perhaps hinting at something more subtle going on with this report.

virgil-palanciuc · 2017-10-20T15:43:32Z

That actually works and is a pretty elegant/quick fix. The only caveat is that you shouldn't pass the span in the tuple... i'm guessing, it messes up the hashcode, and the error ends up being different each time. I can't yet figure out why (complete newbie to the codebase) - so if you want to take up this issue & fix it, please feel free to do so, it'll take me a little while (I'm slow/don't have much time available to work on it :) ).

virgil-palanciuc · 2017-10-24T12:58:37Z

Update - i had some time to inspect it. Basically, the error is reported in two places. Here:

1 | #[macro_use] extern crate log
  |              ^^^^^^^^^^^^^^^^^

and here:

 4 |     info!("This is a log message.");
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The second one is the one that is reported many times - and the primary span seems to be different each time (which is why if you include the span in the "key", it sees the messages as different and emits them all). I'm planning to go from the primary span to file/line/column string, and include that in the message - basically, the key for one_time_diagnostics would be (None, None, modified_message) instead of (None, Some(span), message); this way, we would preserve the first two error messages, but remove the subsequent ones. Still feels a bit hackish, but I don't have a better idea.

zackmdavis · 2017-10-24T16:50:01Z

the primary span seems to be different each time

But they look like they're all pointing to the same code-snippet; what could be making them different? It looks like Spans have a mysterious ctxt field; if that's it, I'd rather manipulate that before setting/getting the one_time_diagnostics entry than pollute the error message string itself with file-position data.

virgil-palanciuc · 2017-10-25T04:12:58Z

So, I printed the location from the span - most of the "repeated" ones are within the macros, e.g.

    Loc {
        file: FileMap(<log macros>),
        line: 5,
        col: CharPos(
            36
        )
    }

I'm pretty sure I need to invoke EmitterWritter::fix_multispan_in_std_macros() on the primary span, in order to retrieve the true location (main.rs, line 4) - only problem is, that method is private. And now it's late :)

I have another idea, I'll try it tomorrow - anyway, this looks to be genuinely trickier than it first appeared to be

…vate'” error is very repetitive

virgil-palanciuc · 2017-10-26T00:04:07Z

Ok guys, I've created PR #45540 - let me know if you think it's a reasonable solution.

Avoid repetition on “use of unstable library feature 'rustc_private'” This PR fixes the error by only emitting it when the span contains a real file (is not inside a macro) - and making sure it's emitted only once per span. The first check was needed because spans-within-macros seem to differ a lot and "fixing" them to the real location is not trivial (and the method that does this is private to another module). It also feels like there always will be an error on import, with the real file name, so not sure there's a point to re-emit the same error at macro use. Fix #44953.

kennytm · 2017-10-29T16:41:33Z

#45540 did not contain the UI test to verify correctness. @virgil-palanciuc could you (or anybody interested) submit another PR to add the test? Sorry for the inconvenience.

virgil-palanciuc · 2017-10-29T22:54:20Z

Just to clarify: the request is that I add a test in src/test/ui that validates this issue is fixed (so that we can't have regressions in the future)? Basically, that means adding the code from the issue in src/test/ui/issue-44953.rs, and the expected output in /src/test/ui/issue-44953.stderr?

If yes - sure, I'll add it, sorry for not adding it from the start, I'm new to this project :).

estebank · 2017-10-30T03:46:46Z

@virgil-palanciuc that is exactly right :)

virgil-palanciuc · 2017-10-30T18:02:02Z

I added the test with PR #45635 ... but, at least on my local build, it seems that the compilation error changed in the meanwhile? (I get a much-more reduced version of it). Not sure why/ if I changed something in the build environment, or the code changed due to other PRs, in main. If the build fails in the PR, I'll need to re-evaluate how to produce a different testcase that still exposes the issue (if it's possible, at at all - I'll may need help on that).

(FWIW, that's why I thought that a test won't be needed for this fix - error output tends to change in time, making such tests a bit fragile)

virgil-palanciuc · 2017-10-30T19:37:42Z

So it wasn't just a thing on my build environment - the error is now simply E0463 can't find crate for log. need to figure out a different test, but it'll probably take me a few days.

jakubadamw · 2017-10-31T08:27:35Z

@virgil-palanciuc, in my opinion the way to go would be to write a complete ui-fulldeps test, so as not to rely on the log crate's rustc_private attribute. Essentially, have an auxiliary crate with the rustc_private configuration attribute (see here) and a test that tries to use it without a #[feature(rustc_private)] attribute. But someone else should also comment if that sounds sensible.

Add test for rust-lang#44953 Added the requested test - trying to see if it passes; my local build fails, but not sure why - the nightly shows this output, but in my build the compilation error changed. Fixes rust-lang#44953.

MIR: adopt borrowck test Fix trailing whitespace span_bug! on unexpected action Make RegionVid use newtype_index! Closes rust-lang#45843 Check rvalue aggregates during check_stmt in tycheck, add initial, (not passing) test Fix failing test Remove attributes and test comments accidentally left behind, add in span_mirbugs Normalize LvalueTy for ops and format code to satisfy tidy check only normalize operand types when in an ADT constructor avoid early return handle the active field index in unions normalize types in ADT constructor Fixes rust-lang#45940 Fix borrowck compiler errors for upvars contain "spurious" dereferences Fixes rust-lang#46003 added associated function Box::leak Box::leak - improve documentation Box::leak - fixed bug in documentation Box::leak - relaxed constraints wrt. lifetimes Box::leak - updated documentation Box::leak - made an oops, fixed now =) Box::leak: update unstable issue number (46179). Add test for rust-lang#44953 Add missing Debug impls to std_unicode Also adds #![deny(missing_debug_implementations)] so they don't get missed again. Amend RELEASES for 1.22.1 and fix the date for 1.22.0 Rename param in `[T]::swap_with_slice` from `src` to `other`. The idea of ‘source’ and ‘destination’ aren’t very applicable for this operation since both slices can both be considered sources and destinations. Clarify stdin behavior of `Command::output`. Fixes rust-lang#44929. Add hints for the case of confusing enum with its variants Add failing testcases Add module population and case of enum in place of expression Use for_each_child_stable in find_module Use multiline text for crate conflict diagnostics Make float::from_bits transmute (and update the documentation to reflect this). The current implementation/documentation was made to avoid sNaN because of potential safety issues implied by old/bad LLVM documentation. These issues aren't real, so we can just make the implementation transmute (as permitted by the existing documentation of this method). Also the documentation didn't actually match the behaviour: it said we may change sNaNs, but in fact we canonicalized *all* NaNs. Also an example in the documentation was wrong: it said we *always* change sNaNs, when the documentation was explicitly written to indicate it was implementation-defined. This makes to_bits and from_bits perfectly roundtrip cross-platform, except for one caveat: although the 2008 edition of IEEE-754 specifies how to interpet the signaling bit, earlier editions didn't. This lead to some platforms picking the opposite interpretation, so all signaling NaNs on x86/ARM are quiet on MIPS, and vice-versa. NaN-boxing is a fairly important optimization, while we don't even guarantee that float operations properly preserve signalingness. As such, this seems like the more natural strategy to take (as opposed to trying to mangle the signaling bit on a per-platform basis). This implementation is also, of course, faster. Simplify an Iterator::fold to Iterator::any This method of once-diagnostics doesn't allow nesting UI tests extract the regular output from the 'rendered' field in json Merge cfail and ui tests into ui tests Add a MIR pass to lower 128-bit operators to lang item calls Runs only with `-Z lower_128bit_ops` since it's not hooked into targets yet. Include tuple projections in MIR tests Add type checking for the lang item As part of doing so, add more lang items instead of passing u128 to the i128 ones where it doesn't matter in twos-complement. Handle shifts properly * The overflow-checking shift items need to take a full 128-bit type, since they need to be able to detect idiocy like `1i128 << (1u128 << 127)` * The unchecked ones just take u32, like the `*_sh?` methods in core * Because shift-by-anything is allowed, cast into a new local for every shift incr.comp.: Make sure we don't lose unused green results from the query cache. rustbuild: Update LLVM and enable ThinLTO This commit updates LLVM to fix rust-lang#45511 (https://reviews.llvm.org/D39981) and also reenables ThinLTO for libtest now that we shouldn't hit rust-lang#45768. This also opportunistically enables ThinLTO for libstd which was previously blocked (rust-lang#45661) on test failures related to debuginfo with a presumed cause of rust-lang#45511. Closes rust-lang#45511 std: Flag Windows TLS dtor symbol as #[used] Turns out ThinLTO was internalizing this symbol and eliminating it. Worse yet if you compiled with LTO turns out no TLS destructors would run on Windows! The `#[used]` annotation should be a more bulletproof implementation (in the face of LTO) of preserving this symbol all the way through in LLVM and ensuring it makes it all the way to the linker which will take care of it. Add enum InitializationRequiringAction Fix tidy tests

It tested rust-lang#44953. `log` macros in newer versions are no longer recursive, so these duplicated error messages (about unstable feature uses) previously occurring at each level of recursion are no longer possible, even with the fix by rust-lang#45540. Furthermore this test breaks when multiple versions of `log` are in the sysroot (`log 0.3.9` depends on`log 0.4.1`)

@ollie27

Add compiler docs testing to CI. Fixes #47025. I don't know if `x86_64-gnu` is the right builder for this, but there seems to be time left on [Travis](https://travis-ci.org/rust-lang/rust/jobs/307488864). Remaining problems blocking this PR: - [x] broken links caused by rustdoc issues: - [x] `pub use self::Enum::...`: #46766 and #46767 (fixed by #47050, thanks @ollie27!) - [x] `impl Deref for DerefToStdType`: #32129 (ignored in linkchecker) - [x] `#[feature(decl_macro)]` and `use std::vec`: #47038 (ignored in linkchecker) - [x] `rustc_data_structures::sync::{Lrc, RwLock}` aliases `std` types: #32130 (ignored in linkchecker) - [x] markdown differences, in rust repository and in external crates, now failing the build with #46880 merged (all fixed) - [x] multiple crate updates needed: `rand`, `log`, `parking_lot_core`, `flate2` - [x] submodule updates needed to deduplicate dependencies: `rust-installer`, ~`cargo`~ (done by #47052) - [x] #44953 test broken by `log` update (removed, this can be controversial) - [x] Waiting `x86_64-gnu` build results ([done](https://travis-ci.org/rust-lang/rust/builds/323451069)) See individual commits for more details.

TimNN added A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. labels Oct 1, 2017

estebank added E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. WG-diagnostics Working group: Diagnostics labels Oct 2, 2017

jakubadamw changed the title ~~The "use of unstable library feature 'rustc_private'" error is very repetitive~~ The “use of unstable library feature 'rustc_private'” error is very repetitive Oct 20, 2017

virgil-palanciuc pushed a commit to virgil-palanciuc/rust that referenced this issue Oct 25, 2017

fix rust-lang#44953 - The “use of unstable library feature 'rustc_pri…

4e16e30

…vate'” error is very repetitive

virgil-palanciuc mentioned this issue Oct 27, 2017

Avoid repetition on “use of unstable library feature 'rustc_private'” #45540

Merged

bors closed this as completed in #45540 Oct 28, 2017

kennytm reopened this Oct 29, 2017

kennytm added E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. and removed E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. labels Oct 29, 2017

virgil-palanciuc mentioned this issue Oct 30, 2017

Add test for #44953 #45635

Merged

virgil-palanciuc added a commit to virgil-palanciuc/rust that referenced this issue Nov 21, 2017

Add test for rust-lang#44953

a2d63d6

bors closed this as completed in #45635 Nov 24, 2017

MaloJaffre mentioned this issue Dec 30, 2017

Add compiler docs testing to CI. #46278

Merged

10 tasks

gilescope mentioned this issue Sep 8, 2019

E0631 has duplicated diagnostics #64165

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

The “use of unstable library feature 'rustc_private'” error is very repetitive #44953

The “use of unstable library feature 'rustc_private'” error is very repetitive #44953

jakubadamw commented Oct 1, 2017 •

edited

Loading

estebank commented Oct 2, 2017

zackmdavis commented Oct 20, 2017

virgil-palanciuc commented Oct 20, 2017

virgil-palanciuc commented Oct 24, 2017

zackmdavis commented Oct 24, 2017

virgil-palanciuc commented Oct 25, 2017 •

edited

Loading

virgil-palanciuc commented Oct 26, 2017

kennytm commented Oct 29, 2017

virgil-palanciuc commented Oct 29, 2017 •

edited

Loading

estebank commented Oct 30, 2017

virgil-palanciuc commented Oct 30, 2017

virgil-palanciuc commented Oct 30, 2017

jakubadamw commented Oct 31, 2017 •

edited

Loading

The “use of unstable library feature 'rustc_private'” error is very repetitive #44953

The “use of unstable library feature 'rustc_private'” error is very repetitive #44953

Comments

jakubadamw commented Oct 1, 2017 • edited Loading

estebank commented Oct 2, 2017

Mentoring instructions

zackmdavis commented Oct 20, 2017

virgil-palanciuc commented Oct 20, 2017

virgil-palanciuc commented Oct 24, 2017

zackmdavis commented Oct 24, 2017

virgil-palanciuc commented Oct 25, 2017 • edited Loading

virgil-palanciuc commented Oct 26, 2017

kennytm commented Oct 29, 2017

virgil-palanciuc commented Oct 29, 2017 • edited Loading

estebank commented Oct 30, 2017

virgil-palanciuc commented Oct 30, 2017

virgil-palanciuc commented Oct 30, 2017

jakubadamw commented Oct 31, 2017 • edited Loading

jakubadamw commented Oct 1, 2017 •

edited

Loading

virgil-palanciuc commented Oct 25, 2017 •

edited

Loading

virgil-palanciuc commented Oct 29, 2017 •

edited

Loading

jakubadamw commented Oct 31, 2017 •

edited

Loading