rust/tests/ui/resolve/issue-30535.stderr

error[E0573]: expected type, found variant `foo::Foo::FooV`
  --> $DIR/issue-30535.rs:6:8
   |
LL |     _: foo::Foo::FooV
   |        ^^^^^^^^^^^^^^
   |        |
   |        not a type
   |        help: try using the variant's enum: `foo::Foo`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0573`.
Moved compile-fail tests to ui tests. 2018-08-08 14:28:26 +02:00			error[E0573]: expected type, found variant `foo::Foo::FooV`
Remove licenses 2018-12-25 08:56:47 -07:00			`--> $DIR/issue-30535.rs:6:8`
Moved compile-fail tests to ui tests. 2018-08-08 14:28:26 +02:00			`\|`
Update tests 2019-03-09 15:03:44 +03:00			`LL \| _: foo::Foo::FooV`
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-18 22:21:38 -08:00			`\| ^^^^^^^^^^^^^^`
			`\| \|`
			`\| not a type`
			\| help: try using the variant's enum: `foo::Foo`
Moved compile-fail tests to ui tests. 2018-08-08 14:28:26 +02:00
			`error: aborting due to previous error`

update ui tests 2019-10-09 14:19:48 +02:00			For more information about this error, try `rustc --explain E0573`.