2019-04-11 21:18:38 +00:00
error[E0658]: use of unstable library feature 'rustc_private': this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via `Cargo.toml` instead?
Support `x test --stage 1 ui-fulldeps`
Nils had an excellent idea the other day: the same way that rustdoc is
able to load `rustc_driver` from the sysroot, ui-fulldeps tests should
also be able to load it from the sysroot. That allows us to run fulldeps
tests with stage1, without having to fully rebuild the compiler twice.
It does unfortunately have the downside that we're running the tests on
the *bootstrap* compiler, not the in-tree sources, but since most of the
fulldeps tests are for the *API* of the compiler, that seems ok.
I think it's possible to extend this to `run-make-fulldeps`, but I've
run out of energy for tonight.
- Move `plugin` tests into a subdirectory.
Plugins are loaded at runtime with `dlopen` and so require the ABI of
the running compile to match the ABI of the compiler linked with
`rustc_driver`. As a result they can't be supported in stage 1 and have
to use `// ignore-stage1`.
- Remove `ignore-stage1` from most non-plugin tests
- Ignore diagnostic tests in stage 1. Even though this requires a stage
2 build to load rustc_driver, it's primarily testing the error message
that the *running* compiler emits when the diagnostic struct is malformed.
- Pass `-Zforce-unstable-if-unmarked` in stage1, not just stage2. That
allows running `hash-stable-is-unstable` in stage1, since it now
suggests adding `rustc_private` to enable loading the crates.
- Add libLLVM.so to the stage0 target sysroot, to allow fulldeps tests
that act as custom drivers to load it at runtime.
- Pass `--sysroot stage0-sysroot` in compiletest so that we use the
correct version of std.
2023-04-18 01:00:36 +00:00
--> $DIR/hash-stable-is-unstable.rs:2:1
2019-03-05 18:28:20 +00:00
|
LL | extern crate rustc_data_structures;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
2020-02-07 12:07:02 +00:00
= note: see issue #27812 <https://github.com/rust-lang/rust/issues/27812> for more information
2019-07-09 09:32:08 +00:00
= help: add `#![feature(rustc_private)]` to the crate attributes to enable
2019-03-05 18:28:20 +00:00
2019-04-11 21:18:38 +00:00
error[E0658]: use of unstable library feature 'rustc_private': this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via `Cargo.toml` instead?
Support `x test --stage 1 ui-fulldeps`
Nils had an excellent idea the other day: the same way that rustdoc is
able to load `rustc_driver` from the sysroot, ui-fulldeps tests should
also be able to load it from the sysroot. That allows us to run fulldeps
tests with stage1, without having to fully rebuild the compiler twice.
It does unfortunately have the downside that we're running the tests on
the *bootstrap* compiler, not the in-tree sources, but since most of the
fulldeps tests are for the *API* of the compiler, that seems ok.
I think it's possible to extend this to `run-make-fulldeps`, but I've
run out of energy for tonight.
- Move `plugin` tests into a subdirectory.
Plugins are loaded at runtime with `dlopen` and so require the ABI of
the running compile to match the ABI of the compiler linked with
`rustc_driver`. As a result they can't be supported in stage 1 and have
to use `// ignore-stage1`.
- Remove `ignore-stage1` from most non-plugin tests
- Ignore diagnostic tests in stage 1. Even though this requires a stage
2 build to load rustc_driver, it's primarily testing the error message
that the *running* compiler emits when the diagnostic struct is malformed.
- Pass `-Zforce-unstable-if-unmarked` in stage1, not just stage2. That
allows running `hash-stable-is-unstable` in stage1, since it now
suggests adding `rustc_private` to enable loading the crates.
- Add libLLVM.so to the stage0 target sysroot, to allow fulldeps tests
that act as custom drivers to load it at runtime.
- Pass `--sysroot stage0-sysroot` in compiletest so that we use the
correct version of std.
2023-04-18 01:00:36 +00:00
--> $DIR/hash-stable-is-unstable.rs:4:1
2019-03-05 18:28:20 +00:00
|
2021-09-26 13:54:02 +00:00
LL | extern crate rustc_macros;
2020-03-29 16:08:01 +00:00
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
2019-03-05 18:28:20 +00:00
|
2020-02-07 12:07:02 +00:00
= note: see issue #27812 <https://github.com/rust-lang/rust/issues/27812> for more information
2019-07-09 09:32:08 +00:00
= help: add `#![feature(rustc_private)]` to the crate attributes to enable
2019-03-05 18:28:20 +00:00
2019-04-11 21:18:38 +00:00
error[E0658]: use of unstable library feature 'rustc_private': this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via `Cargo.toml` instead?
Support `x test --stage 1 ui-fulldeps`
Nils had an excellent idea the other day: the same way that rustdoc is
able to load `rustc_driver` from the sysroot, ui-fulldeps tests should
also be able to load it from the sysroot. That allows us to run fulldeps
tests with stage1, without having to fully rebuild the compiler twice.
It does unfortunately have the downside that we're running the tests on
the *bootstrap* compiler, not the in-tree sources, but since most of the
fulldeps tests are for the *API* of the compiler, that seems ok.
I think it's possible to extend this to `run-make-fulldeps`, but I've
run out of energy for tonight.
- Move `plugin` tests into a subdirectory.
Plugins are loaded at runtime with `dlopen` and so require the ABI of
the running compile to match the ABI of the compiler linked with
`rustc_driver`. As a result they can't be supported in stage 1 and have
to use `// ignore-stage1`.
- Remove `ignore-stage1` from most non-plugin tests
- Ignore diagnostic tests in stage 1. Even though this requires a stage
2 build to load rustc_driver, it's primarily testing the error message
that the *running* compiler emits when the diagnostic struct is malformed.
- Pass `-Zforce-unstable-if-unmarked` in stage1, not just stage2. That
allows running `hash-stable-is-unstable` in stage1, since it now
suggests adding `rustc_private` to enable loading the crates.
- Add libLLVM.so to the stage0 target sysroot, to allow fulldeps tests
that act as custom drivers to load it at runtime.
- Pass `--sysroot stage0-sysroot` in compiletest so that we use the
correct version of std.
2023-04-18 01:00:36 +00:00
--> $DIR/hash-stable-is-unstable.rs:6:1
2019-03-05 18:28:20 +00:00
|
2021-09-26 13:54:02 +00:00
LL | extern crate rustc_query_system;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2019-03-05 18:28:20 +00:00
|
2020-02-07 12:07:02 +00:00
= note: see issue #27812 <https://github.com/rust-lang/rust/issues/27812> for more information
2019-07-09 09:32:08 +00:00
= help: add `#![feature(rustc_private)]` to the crate attributes to enable
2019-03-05 18:28:20 +00:00
2019-04-11 21:18:38 +00:00
error[E0658]: use of unstable library feature 'rustc_private': this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via `Cargo.toml` instead?
Support `x test --stage 1 ui-fulldeps`
Nils had an excellent idea the other day: the same way that rustdoc is
able to load `rustc_driver` from the sysroot, ui-fulldeps tests should
also be able to load it from the sysroot. That allows us to run fulldeps
tests with stage1, without having to fully rebuild the compiler twice.
It does unfortunately have the downside that we're running the tests on
the *bootstrap* compiler, not the in-tree sources, but since most of the
fulldeps tests are for the *API* of the compiler, that seems ok.
I think it's possible to extend this to `run-make-fulldeps`, but I've
run out of energy for tonight.
- Move `plugin` tests into a subdirectory.
Plugins are loaded at runtime with `dlopen` and so require the ABI of
the running compile to match the ABI of the compiler linked with
`rustc_driver`. As a result they can't be supported in stage 1 and have
to use `// ignore-stage1`.
- Remove `ignore-stage1` from most non-plugin tests
- Ignore diagnostic tests in stage 1. Even though this requires a stage
2 build to load rustc_driver, it's primarily testing the error message
that the *running* compiler emits when the diagnostic struct is malformed.
- Pass `-Zforce-unstable-if-unmarked` in stage1, not just stage2. That
allows running `hash-stable-is-unstable` in stage1, since it now
suggests adding `rustc_private` to enable loading the crates.
- Add libLLVM.so to the stage0 target sysroot, to allow fulldeps tests
that act as custom drivers to load it at runtime.
- Pass `--sysroot stage0-sysroot` in compiletest so that we use the
correct version of std.
2023-04-18 01:00:36 +00:00
--> $DIR/hash-stable-is-unstable.rs:9:5
2019-03-05 18:28:20 +00:00
|
LL | use rustc_macros::HashStable;
| ^^^^^^^^^^^^^^^^^^^^^^^^
|
2020-02-07 12:07:02 +00:00
= note: see issue #27812 <https://github.com/rust-lang/rust/issues/27812> for more information
2019-07-09 09:32:08 +00:00
= help: add `#![feature(rustc_private)]` to the crate attributes to enable
2019-03-05 18:28:20 +00:00
2019-04-11 21:18:38 +00:00
error[E0658]: use of unstable library feature 'rustc_private': this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via `Cargo.toml` instead?
Support `x test --stage 1 ui-fulldeps`
Nils had an excellent idea the other day: the same way that rustdoc is
able to load `rustc_driver` from the sysroot, ui-fulldeps tests should
also be able to load it from the sysroot. That allows us to run fulldeps
tests with stage1, without having to fully rebuild the compiler twice.
It does unfortunately have the downside that we're running the tests on
the *bootstrap* compiler, not the in-tree sources, but since most of the
fulldeps tests are for the *API* of the compiler, that seems ok.
I think it's possible to extend this to `run-make-fulldeps`, but I've
run out of energy for tonight.
- Move `plugin` tests into a subdirectory.
Plugins are loaded at runtime with `dlopen` and so require the ABI of
the running compile to match the ABI of the compiler linked with
`rustc_driver`. As a result they can't be supported in stage 1 and have
to use `// ignore-stage1`.
- Remove `ignore-stage1` from most non-plugin tests
- Ignore diagnostic tests in stage 1. Even though this requires a stage
2 build to load rustc_driver, it's primarily testing the error message
that the *running* compiler emits when the diagnostic struct is malformed.
- Pass `-Zforce-unstable-if-unmarked` in stage1, not just stage2. That
allows running `hash-stable-is-unstable` in stage1, since it now
suggests adding `rustc_private` to enable loading the crates.
- Add libLLVM.so to the stage0 target sysroot, to allow fulldeps tests
that act as custom drivers to load it at runtime.
- Pass `--sysroot stage0-sysroot` in compiletest so that we use the
correct version of std.
2023-04-18 01:00:36 +00:00
--> $DIR/hash-stable-is-unstable.rs:12:10
2019-03-05 18:28:20 +00:00
|
LL | #[derive(HashStable)]
| ^^^^^^^^^^
|
2020-02-07 12:07:02 +00:00
= note: see issue #27812 <https://github.com/rust-lang/rust/issues/27812> for more information
2019-07-09 09:32:08 +00:00
= help: add `#![feature(rustc_private)]` to the crate attributes to enable
2021-02-13 19:52:25 +00:00
= note: this error originates in the derive macro `HashStable` (in Nightly builds, run with -Z macro-backtrace for more info)
2019-03-05 18:28:20 +00:00
2019-09-08 17:06:49 +00:00
error: aborting due to 5 previous errors
2019-03-05 18:28:20 +00:00
2019-09-08 17:06:49 +00:00
For more information about this error, try `rustc --explain E0658`.
