mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
5212fbc51d
rust/tests/ui/imports/import-from-missing-star-3.stderr

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

26 lines
610 B
Plaintext
Raw Normal View History

Silence some resolve errors when there have been glob import errors When encountering `use foo::*;` where `foo` fails to be found, and we later encounter resolution errors, we silence those later errors. A single case of the above, for an *existing* import on a big codebase would otherwise have a huge number of knock-down spurious errors. Ideally, instead of a global flag to silence all subsequent resolve errors, we'd want to introduce an unameable binding in the appropriate rib as a sentinel when there's a failed glob import, so when we encounter a resolve error we can search for that sentinel and if found, and only then, silence that error. The current approach is just a quick proof of concept to iterate over. Partially address #96799.
2024-05-21 14:12:05 -05:00
error[E0432]: unresolved import `spam`
--> $DIR/import-from-missing-star-3.rs:2:9
|
LL | use spam::*;
Do not use question as label We don't want to have questions in the diagnostic output. Instead, we use wording that communicates uncertainty, like "might": ``` error[E0432]: unresolved import `spam` --> $DIR/import-from-missing-star-3.rs:2:9 | LL | use spam::*; | ^^^^ you might be missing crate `spam` | = help: consider adding `extern crate spam` to use the `spam` crate ```
2024-07-23 14:43:46 -05:00
| ^^^^ you might be missing crate `spam`
Silence some resolve errors when there have been glob import errors When encountering `use foo::*;` where `foo` fails to be found, and we later encounter resolution errors, we silence those later errors. A single case of the above, for an *existing* import on a big codebase would otherwise have a huge number of knock-down spurious errors. Ideally, instead of a global flag to silence all subsequent resolve errors, we'd want to introduce an unameable binding in the appropriate rib as a sentinel when there's a failed glob import, so when we encounter a resolve error we can search for that sentinel and if found, and only then, silence that error. The current approach is just a quick proof of concept to iterate over. Partially address #96799.
2024-05-21 14:12:05 -05:00
|
Structured suggestion for `extern crate foo` when `foo` isn't resolved in import When encountering a name in an import that could have come from a crate that wasn't imported, use a structured suggestion to suggest `extern crate foo;` pointing at the right place in the crate. When encountering `_` in an import, do not suggest `extern crate _;`. ``` error[E0432]: unresolved import `spam` --> $DIR/import-from-missing-star-3.rs:2:9 | LL | use spam::*; | ^^^^ maybe a missing crate `spam`? | help: consider importing the `spam` crate | LL + extern crate spam; | ```
2024-07-24 14:31:02 -05:00
help: consider importing the `spam` crate
|
LL + extern crate spam;
|
Silence some resolve errors when there have been glob import errors When encountering `use foo::*;` where `foo` fails to be found, and we later encounter resolution errors, we silence those later errors. A single case of the above, for an *existing* import on a big codebase would otherwise have a huge number of knock-down spurious errors. Ideally, instead of a global flag to silence all subsequent resolve errors, we'd want to introduce an unameable binding in the appropriate rib as a sentinel when there's a failed glob import, so when we encounter a resolve error we can search for that sentinel and if found, and only then, silence that error. The current approach is just a quick proof of concept to iterate over. Partially address #96799.
2024-05-21 14:12:05 -05:00
error[E0432]: unresolved import `spam`
--> $DIR/import-from-missing-star-3.rs:27:13
|
LL | use spam::*;
Do not use question as label We don't want to have questions in the diagnostic output. Instead, we use wording that communicates uncertainty, like "might": ``` error[E0432]: unresolved import `spam` --> $DIR/import-from-missing-star-3.rs:2:9 | LL | use spam::*; | ^^^^ you might be missing crate `spam` | = help: consider adding `extern crate spam` to use the `spam` crate ```
2024-07-23 14:43:46 -05:00
| ^^^^ you might be missing crate `spam`
Silence some resolve errors when there have been glob import errors When encountering `use foo::*;` where `foo` fails to be found, and we later encounter resolution errors, we silence those later errors. A single case of the above, for an *existing* import on a big codebase would otherwise have a huge number of knock-down spurious errors. Ideally, instead of a global flag to silence all subsequent resolve errors, we'd want to introduce an unameable binding in the appropriate rib as a sentinel when there's a failed glob import, so when we encounter a resolve error we can search for that sentinel and if found, and only then, silence that error. The current approach is just a quick proof of concept to iterate over. Partially address #96799.
2024-05-21 14:12:05 -05:00
|
Structured suggestion for `extern crate foo` when `foo` isn't resolved in import When encountering a name in an import that could have come from a crate that wasn't imported, use a structured suggestion to suggest `extern crate foo;` pointing at the right place in the crate. When encountering `_` in an import, do not suggest `extern crate _;`. ``` error[E0432]: unresolved import `spam` --> $DIR/import-from-missing-star-3.rs:2:9 | LL | use spam::*; | ^^^^ maybe a missing crate `spam`? | help: consider importing the `spam` crate | LL + extern crate spam; | ```
2024-07-24 14:31:02 -05:00
help: consider importing the `spam` crate
|
LL + extern crate spam;
|
Silence some resolve errors when there have been glob import errors When encountering `use foo::*;` where `foo` fails to be found, and we later encounter resolution errors, we silence those later errors. A single case of the above, for an *existing* import on a big codebase would otherwise have a huge number of knock-down spurious errors. Ideally, instead of a global flag to silence all subsequent resolve errors, we'd want to introduce an unameable binding in the appropriate rib as a sentinel when there's a failed glob import, so when we encounter a resolve error we can search for that sentinel and if found, and only then, silence that error. The current approach is just a quick proof of concept to iterate over. Partially address #96799.
2024-05-21 14:12:05 -05:00
error: aborting due to 2 previous errors
For more information about this error, try `rustc --explain E0432`.
Reference in New Issue Copy Permalink