mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
50a46710a9
rust/tests/ui/lint/issue-35075.stderr

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

26 lines
653 B
Plaintext
Raw Normal View History

Move some `compile-fail` tests to `ui`
2018-07-15 16:11:54 -05:00
error[E0412]: cannot find type `Foo` in this scope
Remove licenses
2018-12-25 09:56:47 -06:00
--> $DIR/issue-35075.rs:2:12
Move some `compile-fail` tests to `ui`
2018-07-15 16:11:54 -05:00
|
Update tests
2019-03-09 06:03:44 -06:00
LL | inner: Foo<T>
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
Increase spacing for suggestions in diagnostics Make the spacing between the code snippet and verbose structured suggestions consistent with note and help messages.
2019-10-24 00:20:58 -05:00
|
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
help: there is an enum variant `Baz::Foo`; try using the variant's enum
|
Update tests
2019-03-09 06:03:44 -06:00
LL | inner: Baz
Modify structured suggestion output * On suggestions that include deletions, use a diff inspired output format * When suggesting addition, use `+` as underline * Color highlight modified span
2021-06-21 21:07:19 -05:00
| ~~~
Move some `compile-fail` tests to `ui`
2018-07-15 16:11:54 -05:00
error[E0412]: cannot find type `Foo` in this scope
Remove licenses
2018-12-25 09:56:47 -06:00
--> $DIR/issue-35075.rs:6:9
Move some `compile-fail` tests to `ui`
2018-07-15 16:11:54 -05:00
|
Update tests
2019-03-09 06:03:44 -06:00
LL | Foo(Foo<T>)
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
Increase spacing for suggestions in diagnostics Make the spacing between the code snippet and verbose structured suggestions consistent with note and help messages.
2019-10-24 00:20:58 -05:00
|
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
help: there is an enum variant `Baz::Foo`; try using the variant's enum
|
Update tests
2019-03-09 06:03:44 -06:00
LL | Foo(Baz)
Modify structured suggestion output * On suggestions that include deletions, use a diff inspired output format * When suggesting addition, use `+` as underline * Color highlight modified span
2021-06-21 21:07:19 -05:00
| ~~~
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`.
Reference in New Issue Copy Permalink