rust/src/test/ui/issues/issue-35075.stderr

error[E0412]: cannot find type `Foo` in this scope
  --> $DIR/issue-35075.rs:12:12
   |
LL |     inner: Foo<T> //~ ERROR cannot find type `Foo` in this scope
   |            ^^^ not found in this scope
help: there is an enum variant `Baz::Foo`; try using the variant's enum
   |
LL |     inner: Baz //~ ERROR cannot find type `Foo` in this scope
   |            ^^^

error[E0412]: cannot find type `Foo` in this scope
  --> $DIR/issue-35075.rs:16:9
   |
LL |     Foo(Foo<T>) //~ ERROR cannot find type `Foo` in this scope
   |         ^^^ not found in this scope
help: there is an enum variant `Baz::Foo`; try using the variant's enum
   |
LL |     Foo(Baz) //~ ERROR cannot find type `Foo` in this scope
   |         ^^^

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0412`.
Move some `compile-fail` tests to `ui` 2018-07-15 16:11:54 -05:00			error[E0412]: cannot find type `Foo` in this scope
			`--> $DIR/issue-35075.rs:12:12`
			`\|`
			LL \| inner: Foo<T> //~ ERROR cannot find type `Foo` in this scope
enum type instead of variant suggestion unification Weirdly, we were deciding between a help note and a structured suggestion based on whether the import candidate span was a dummy—but we weren't using that span in any case! The dummy-ness of the span (which appears to be a matter of this-crate vs. other-crate definition) isn't the right criterion by which we should decide whether it's germane to mention that "there is an enum variant"; instead, let's use the someness of `def` (which is used as the `has_unexpected_resolution` argument to `error_code`). Since `import_candidate_to_paths` has no other callers, we are free to stop returning the span and rename the function. By using `span_suggestions_`, we leverage the max-suggestions output limit already built in to the emitter, thus resolving #56028. In the matter of message wording, "you can" is redundant (and perhaps too informal); prefer the imperative. 2018-11-19 00:21:38 -06:00			`\| ^^^ not found in this scope`
			help: there is an enum variant `Baz::Foo`; try using the variant's enum
			`\|`
			LL \| inner: Baz //~ ERROR cannot find type `Foo` in this scope
			`\| ^^^`
Move some `compile-fail` tests to `ui` 2018-07-15 16:11:54 -05:00
			error[E0412]: cannot find type `Foo` in this scope
			`--> $DIR/issue-35075.rs:16:9`
			`\|`
			LL \| Foo(Foo<T>) //~ ERROR cannot find type `Foo` in this scope
enum type instead of variant suggestion unification Weirdly, we were deciding between a help note and a structured suggestion based on whether the import candidate span was a dummy—but we weren't using that span in any case! The dummy-ness of the span (which appears to be a matter of this-crate vs. other-crate definition) isn't the right criterion by which we should decide whether it's germane to mention that "there is an enum variant"; instead, let's use the someness of `def` (which is used as the `has_unexpected_resolution` argument to `error_code`). Since `import_candidate_to_paths` has no other callers, we are free to stop returning the span and rename the function. By using `span_suggestions_`, we leverage the max-suggestions output limit already built in to the emitter, thus resolving #56028. In the matter of message wording, "you can" is redundant (and perhaps too informal); prefer the imperative. 2018-11-19 00:21:38 -06:00			`\| ^^^ not found in this scope`
			help: there is an enum variant `Baz::Foo`; try using the variant's enum
			`\|`
			LL \| Foo(Baz) //~ ERROR cannot find type `Foo` in this scope
			`\| ^^^`
Move some `compile-fail` tests to `ui` 2018-07-15 16:11:54 -05:00
			`error: aborting due to 2 previous errors`

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