mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
1b98ae3ecd
rust/tests/ui/cfg/diagnostics-cross-crate.stderr

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

79 lines
2.4 KiB
Plaintext
Raw Normal View History

Remember names of `cfg`-ed out items to mention them in diagnostics `#[cfg]`s are frequently used to gate crate content behind cargo features. This can lead to very confusing errors when features are missing. For example, `serde` doesn't have the `derive` feature by default. Therefore, `serde::Serialize` fails to resolve with a generic error, even though the macro is present in the docs. This commit adds a list of all stripped item names to metadata. This is filled during macro expansion and then, through a fed query, persisted in metadata. The downstream resolver can then access the metadata to look at possible candidates for mentioning in the errors. This slightly increases metadata (800k->809k for the feature-heavy windows crate), but not enough to really matter.
2023-03-10 15:39:14 -06:00
error[E0433]: failed to resolve: could not find `doesnt_exist` in `inner`
When finding item gated behind a `cfg` flat, point at it Previously we would only mention that the item was gated out, and opportunisitically mention the feature flag name when possible. We now point to the place where the item was gated, which can be behind layers of macro indirection, or in different modules. ``` error[E0433]: failed to resolve: could not find `doesnt_exist` in `inner` --> $DIR/diagnostics-cross-crate.rs:18:23 | LL | cfged_out::inner::doesnt_exist::hello(); | ^^^^^^^^^^^^ could not find `doesnt_exist` in `inner` | note: found an item that was configured out --> $DIR/auxiliary/cfged_out.rs:6:13 | LL | pub mod doesnt_exist { | ^^^^^^^^^^^^ note: the item is gated here --> $DIR/auxiliary/cfged_out.rs:5:5 | LL | #[cfg(FALSE)] | ^^^^^^^^^^^^^ ```
2024-07-12 13:52:52 -05:00
--> $DIR/diagnostics-cross-crate.rs:18:23
Remember names of `cfg`-ed out items to mention them in diagnostics `#[cfg]`s are frequently used to gate crate content behind cargo features. This can lead to very confusing errors when features are missing. For example, `serde` doesn't have the `derive` feature by default. Therefore, `serde::Serialize` fails to resolve with a generic error, even though the macro is present in the docs. This commit adds a list of all stripped item names to metadata. This is filled during macro expansion and then, through a fed query, persisted in metadata. The downstream resolver can then access the metadata to look at possible candidates for mentioning in the errors. This slightly increases metadata (800k->809k for the feature-heavy windows crate), but not enough to really matter.
2023-03-10 15:39:14 -06:00
|
LL | cfged_out::inner::doesnt_exist::hello();
| ^^^^^^^^^^^^ could not find `doesnt_exist` in `inner`
store the segment name when resolution fails
2024-01-13 07:05:41 -06:00
|
note: found an item that was configured out
--> $DIR/auxiliary/cfged_out.rs:6:13
|
LL | pub mod doesnt_exist {
| ^^^^^^^^^^^^
When finding item gated behind a `cfg` flat, point at it Previously we would only mention that the item was gated out, and opportunisitically mention the feature flag name when possible. We now point to the place where the item was gated, which can be behind layers of macro indirection, or in different modules. ``` error[E0433]: failed to resolve: could not find `doesnt_exist` in `inner` --> $DIR/diagnostics-cross-crate.rs:18:23 | LL | cfged_out::inner::doesnt_exist::hello(); | ^^^^^^^^^^^^ could not find `doesnt_exist` in `inner` | note: found an item that was configured out --> $DIR/auxiliary/cfged_out.rs:6:13 | LL | pub mod doesnt_exist { | ^^^^^^^^^^^^ note: the item is gated here --> $DIR/auxiliary/cfged_out.rs:5:5 | LL | #[cfg(FALSE)] | ^^^^^^^^^^^^^ ```
2024-07-12 13:52:52 -05:00
note: the item is gated here
--> $DIR/auxiliary/cfged_out.rs:5:5
|
LL | #[cfg(FALSE)]
| ^^^^^^^^^^^^^
Remember names of `cfg`-ed out items to mention them in diagnostics `#[cfg]`s are frequently used to gate crate content behind cargo features. This can lead to very confusing errors when features are missing. For example, `serde` doesn't have the `derive` feature by default. Therefore, `serde::Serialize` fails to resolve with a generic error, even though the macro is present in the docs. This commit adds a list of all stripped item names to metadata. This is filled during macro expansion and then, through a fed query, persisted in metadata. The downstream resolver can then access the metadata to look at possible candidates for mentioning in the errors. This slightly increases metadata (800k->809k for the feature-heavy windows crate), but not enough to really matter.
2023-03-10 15:39:14 -06:00
error[E0425]: cannot find function `uwu` in crate `cfged_out`
--> $DIR/diagnostics-cross-crate.rs:7:16
|
LL | cfged_out::uwu();
| ^^^ not found in `cfged_out`
error[E0425]: cannot find function `uwu` in module `cfged_out::inner`
--> $DIR/diagnostics-cross-crate.rs:11:23
|
LL | cfged_out::inner::uwu();
| ^^^ not found in `cfged_out::inner`
|
note: found an item that was configured out
--> $DIR/auxiliary/cfged_out.rs:3:12
|
LL | pub fn uwu() {}
| ^^^
When finding item gated behind a `cfg` flat, point at it Previously we would only mention that the item was gated out, and opportunisitically mention the feature flag name when possible. We now point to the place where the item was gated, which can be behind layers of macro indirection, or in different modules. ``` error[E0433]: failed to resolve: could not find `doesnt_exist` in `inner` --> $DIR/diagnostics-cross-crate.rs:18:23 | LL | cfged_out::inner::doesnt_exist::hello(); | ^^^^^^^^^^^^ could not find `doesnt_exist` in `inner` | note: found an item that was configured out --> $DIR/auxiliary/cfged_out.rs:6:13 | LL | pub mod doesnt_exist { | ^^^^^^^^^^^^ note: the item is gated here --> $DIR/auxiliary/cfged_out.rs:5:5 | LL | #[cfg(FALSE)] | ^^^^^^^^^^^^^ ```
2024-07-12 13:52:52 -05:00
note: the item is gated here
--> $DIR/auxiliary/cfged_out.rs:2:5
|
LL | #[cfg(FALSE)]
| ^^^^^^^^^^^^^
Remember names of `cfg`-ed out items to mention them in diagnostics `#[cfg]`s are frequently used to gate crate content behind cargo features. This can lead to very confusing errors when features are missing. For example, `serde` doesn't have the `derive` feature by default. Therefore, `serde::Serialize` fails to resolve with a generic error, even though the macro is present in the docs. This commit adds a list of all stripped item names to metadata. This is filled during macro expansion and then, through a fed query, persisted in metadata. The downstream resolver can then access the metadata to look at possible candidates for mentioning in the errors. This slightly increases metadata (800k->809k for the feature-heavy windows crate), but not enough to really matter.
2023-03-10 15:39:14 -06:00
error[E0425]: cannot find function `meow` in module `cfged_out::inner::right`
When finding item gated behind a `cfg` flat, point at it Previously we would only mention that the item was gated out, and opportunisitically mention the feature flag name when possible. We now point to the place where the item was gated, which can be behind layers of macro indirection, or in different modules. ``` error[E0433]: failed to resolve: could not find `doesnt_exist` in `inner` --> $DIR/diagnostics-cross-crate.rs:18:23 | LL | cfged_out::inner::doesnt_exist::hello(); | ^^^^^^^^^^^^ could not find `doesnt_exist` in `inner` | note: found an item that was configured out --> $DIR/auxiliary/cfged_out.rs:6:13 | LL | pub mod doesnt_exist { | ^^^^^^^^^^^^ note: the item is gated here --> $DIR/auxiliary/cfged_out.rs:5:5 | LL | #[cfg(FALSE)] | ^^^^^^^^^^^^^ ```
2024-07-12 13:52:52 -05:00
--> $DIR/diagnostics-cross-crate.rs:24:30
Remember names of `cfg`-ed out items to mention them in diagnostics `#[cfg]`s are frequently used to gate crate content behind cargo features. This can lead to very confusing errors when features are missing. For example, `serde` doesn't have the `derive` feature by default. Therefore, `serde::Serialize` fails to resolve with a generic error, even though the macro is present in the docs. This commit adds a list of all stripped item names to metadata. This is filled during macro expansion and then, through a fed query, persisted in metadata. The downstream resolver can then access the metadata to look at possible candidates for mentioning in the errors. This slightly increases metadata (800k->809k for the feature-heavy windows crate), but not enough to really matter.
2023-03-10 15:39:14 -06:00
|
LL | cfged_out::inner::right::meow();
| ^^^^ not found in `cfged_out::inner::right`
|
note: found an item that was configured out
--> $DIR/auxiliary/cfged_out.rs:17:16
|
LL | pub fn meow() {}
| ^^^^
When finding item gated behind a `cfg` flat, point at it Previously we would only mention that the item was gated out, and opportunisitically mention the feature flag name when possible. We now point to the place where the item was gated, which can be behind layers of macro indirection, or in different modules. ``` error[E0433]: failed to resolve: could not find `doesnt_exist` in `inner` --> $DIR/diagnostics-cross-crate.rs:18:23 | LL | cfged_out::inner::doesnt_exist::hello(); | ^^^^^^^^^^^^ could not find `doesnt_exist` in `inner` | note: found an item that was configured out --> $DIR/auxiliary/cfged_out.rs:6:13 | LL | pub mod doesnt_exist { | ^^^^^^^^^^^^ note: the item is gated here --> $DIR/auxiliary/cfged_out.rs:5:5 | LL | #[cfg(FALSE)] | ^^^^^^^^^^^^^ ```
2024-07-12 13:52:52 -05:00
note: the item is gated behind the `what-a-cool-feature` feature
--> $DIR/auxiliary/cfged_out.rs:16:15
|
LL | #[cfg(feature = "what-a-cool-feature")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Remember names of `cfg`-ed out items to mention them in diagnostics `#[cfg]`s are frequently used to gate crate content behind cargo features. This can lead to very confusing errors when features are missing. For example, `serde` doesn't have the `derive` feature by default. Therefore, `serde::Serialize` fails to resolve with a generic error, even though the macro is present in the docs. This commit adds a list of all stripped item names to metadata. This is filled during macro expansion and then, through a fed query, persisted in metadata. The downstream resolver can then access the metadata to look at possible candidates for mentioning in the errors. This slightly increases metadata (800k->809k for the feature-heavy windows crate), but not enough to really matter.
2023-03-10 15:39:14 -06:00
error[E0425]: cannot find function `vanished` in crate `cfged_out`
When finding item gated behind a `cfg` flat, point at it Previously we would only mention that the item was gated out, and opportunisitically mention the feature flag name when possible. We now point to the place where the item was gated, which can be behind layers of macro indirection, or in different modules. ``` error[E0433]: failed to resolve: could not find `doesnt_exist` in `inner` --> $DIR/diagnostics-cross-crate.rs:18:23 | LL | cfged_out::inner::doesnt_exist::hello(); | ^^^^^^^^^^^^ could not find `doesnt_exist` in `inner` | note: found an item that was configured out --> $DIR/auxiliary/cfged_out.rs:6:13 | LL | pub mod doesnt_exist { | ^^^^^^^^^^^^ note: the item is gated here --> $DIR/auxiliary/cfged_out.rs:5:5 | LL | #[cfg(FALSE)] | ^^^^^^^^^^^^^ ```
2024-07-12 13:52:52 -05:00
--> $DIR/diagnostics-cross-crate.rs:30:16
Remember names of `cfg`-ed out items to mention them in diagnostics `#[cfg]`s are frequently used to gate crate content behind cargo features. This can lead to very confusing errors when features are missing. For example, `serde` doesn't have the `derive` feature by default. Therefore, `serde::Serialize` fails to resolve with a generic error, even though the macro is present in the docs. This commit adds a list of all stripped item names to metadata. This is filled during macro expansion and then, through a fed query, persisted in metadata. The downstream resolver can then access the metadata to look at possible candidates for mentioning in the errors. This slightly increases metadata (800k->809k for the feature-heavy windows crate), but not enough to really matter.
2023-03-10 15:39:14 -06:00
|
LL | cfged_out::vanished();
| ^^^^^^^^ not found in `cfged_out`
|
note: found an item that was configured out
--> $DIR/auxiliary/cfged_out.rs:22:8
|
LL | pub fn vanished() {}
| ^^^^^^^^
When finding item gated behind a `cfg` flat, point at it Previously we would only mention that the item was gated out, and opportunisitically mention the feature flag name when possible. We now point to the place where the item was gated, which can be behind layers of macro indirection, or in different modules. ``` error[E0433]: failed to resolve: could not find `doesnt_exist` in `inner` --> $DIR/diagnostics-cross-crate.rs:18:23 | LL | cfged_out::inner::doesnt_exist::hello(); | ^^^^^^^^^^^^ could not find `doesnt_exist` in `inner` | note: found an item that was configured out --> $DIR/auxiliary/cfged_out.rs:6:13 | LL | pub mod doesnt_exist { | ^^^^^^^^^^^^ note: the item is gated here --> $DIR/auxiliary/cfged_out.rs:5:5 | LL | #[cfg(FALSE)] | ^^^^^^^^^^^^^ ```
2024-07-12 13:52:52 -05:00
note: the item is gated here
--> $DIR/auxiliary/cfged_out.rs:21:1
|
LL | #[cfg(i_dont_exist_and_you_can_do_nothing_about_it)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Remember names of `cfg`-ed out items to mention them in diagnostics `#[cfg]`s are frequently used to gate crate content behind cargo features. This can lead to very confusing errors when features are missing. For example, `serde` doesn't have the `derive` feature by default. Therefore, `serde::Serialize` fails to resolve with a generic error, even though the macro is present in the docs. This commit adds a list of all stripped item names to metadata. This is filled during macro expansion and then, through a fed query, persisted in metadata. The downstream resolver can then access the metadata to look at possible candidates for mentioning in the errors. This slightly increases metadata (800k->809k for the feature-heavy windows crate), but not enough to really matter.
2023-03-10 15:39:14 -06:00
error: aborting due to 5 previous errors
Some errors have detailed explanations: E0425, E0433.
For more information about an error, try `rustc --explain E0425`.
Reference in New Issue Copy Permalink