rust/tests/ui/imports/import-from-missing-star.stderr

error[E0432]: unresolved import `spam`
  --> $DIR/import-from-missing-star.rs:1:5
   |
LL | use spam::*;
   |     ^^^^ you might be missing crate `spam`
   |
help: consider importing the `spam` crate
   |
LL + extern crate spam;
   |

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0432`.
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.rs:1:5`
			`\|`
			`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 1 previous error`

			For more information about this error, try `rustc --explain E0432`.