nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2024-12-02 11:44:28 +00:00
Code Issues Packages Projects Releases Wiki Activity
f22a0c2d9f
rust/tests/ui/lint/issue-35075.stderr

26 lines
653 B
Plaintext
Raw Normal View History

Move some `compile-fail` tests to `ui`
2018-07-15 21:11:54 +00:00
error[E0412]: cannot find type `Foo` in this scope
Remove licenses
2018-12-25 15:56:47 +00:00
--> $DIR/issue-35075.rs:2:12
Move some `compile-fail` tests to `ui`
2018-07-15 21:11:54 +00:00
|
Update tests
2019-03-09 12:03:44 +00: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 06:21:38 +00: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 05:20:58 +00: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 06:21:38 +00:00
help: there is an enum variant `Baz::Foo`; try using the variant's enum
|
Update tests
2019-03-09 12:03:44 +00: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-22 02:07:19 +00:00
| ~~~
Move some `compile-fail` tests to `ui`
2018-07-15 21:11:54 +00:00
error[E0412]: cannot find type `Foo` in this scope
Remove licenses
2018-12-25 15:56:47 +00:00
--> $DIR/issue-35075.rs:6:9
Move some `compile-fail` tests to `ui`
2018-07-15 21:11:54 +00:00
|
Update tests
2019-03-09 12:03:44 +00: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 06:21:38 +00: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 05:20:58 +00: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 06:21:38 +00:00
help: there is an enum variant `Baz::Foo`; try using the variant's enum
|
Update tests
2019-03-09 12:03:44 +00: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-22 02:07:19 +00:00
| ~~~
Move some `compile-fail` tests to `ui`
2018-07-15 21:11:54 +00:00
error: aborting due to 2 previous errors
For more information about this error, try `rustc --explain E0412`.
Reference in New Issue Copy Permalink