mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
515bdcda01
rust/tests/ui/cfg/diagnostics-reexport.stderr

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

68 lines
1.7 KiB
Plaintext
Raw Normal View History

fix: add cfg diagnostic for unresolved import error
2023-06-20 13:20:55 -05:00
error[E0432]: unresolved import `a::x`
--> $DIR/diagnostics-reexport.rs:12:9
|
LL | pub use a::x;
| ^^^^ no `x` in `a`
|
note: found an item that was configured out
--> $DIR/diagnostics-reexport.rs:18:12
|
LL | pub fn x() {}
| ^
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/diagnostics-reexport.rs:17:5
|
LL | #[cfg(FALSE)]
| ^^^^^^^^^^^^^
fix: add cfg diagnostic for unresolved import error
2023-06-20 13:20:55 -05:00
error[E0432]: unresolved imports `b::x`, `b::y`
--> $DIR/diagnostics-reexport.rs:22:13
|
LL | pub use b::{x, y};
| ^ ^ no `y` in `b`
| |
| no `x` in `b`
|
note: found an item that was configured out
--> $DIR/diagnostics-reexport.rs:29:12
|
LL | pub fn x() {}
| ^
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/diagnostics-reexport.rs:28:5
|
LL | #[cfg(FALSE)]
| ^^^^^^^^^^^^^
fix: add cfg diagnostic for unresolved import error
2023-06-20 13:20:55 -05:00
note: found an item that was configured out
--> $DIR/diagnostics-reexport.rs:32:12
|
LL | pub fn y() {}
| ^
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/diagnostics-reexport.rs:31:5
|
LL | #[cfg(FALSE)]
| ^^^^^^^^^^^^^
fix: add cfg diagnostic for unresolved import error
2023-06-20 13:20:55 -05:00
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 module `inner`
fix: add cfg diagnostic for unresolved import error
2023-06-20 13:20:55 -05:00
--> $DIR/diagnostics-reexport.rs:38:12
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 | inner::uwu();
| ^^^ not found in `inner`
|
note: found an item that was configured out
--> $DIR/diagnostics-reexport.rs:8:20
|
LL | pub use super::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/diagnostics-reexport.rs:7: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
fix: add cfg diagnostic for unresolved import error
2023-06-20 13:20:55 -05:00
error: aborting due to 3 previous errors
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
fix: add cfg diagnostic for unresolved import error
2023-06-20 13:20:55 -05:00
Some errors have detailed explanations: E0425, E0432.
For more information about an error, try `rustc --explain E0425`.
Reference in New Issue Copy Permalink