mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
21bcd2ee9c
rust/tests/ui/did_you_mean/issue-56028-there-is-an-enum-variant.stderr

41 lines
1.1 KiB
Plaintext
Raw Normal View History

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
error[E0412]: cannot find type `Set` in this scope
--> $DIR/issue-56028-there-is-an-enum-variant.rs:9:15
|
LL | fn setup() -> Set { Set }
| ^^^ 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 `AffixHeart::Set` and 7 others; try using the variant's enum
|
LL | fn setup() -> AffixHeart { Set }
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
| ~~~~~~~~~~
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
LL | fn setup() -> CauseToBe { Set }
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
| ~~~~~~~~~
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
LL | fn setup() -> Determine { Set }
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
| ~~~~~~~~~
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
LL | fn setup() -> PutDown { Set }
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
| ~~~~~~~
Bring attention to suggestions when the only difference is capitalization
2019-10-13 23:48:39 -05:00
and 3 other candidates
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
error[E0425]: cannot find value `Set` in this scope
--> $DIR/issue-56028-there-is-an-enum-variant.rs:9:21
|
LL | fn setup() -> Set { Set }
| ^^^ 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
|
reword "possible candidate" import suggestion
2020-05-04 17:12:06 -05:00
help: consider importing one of these items
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
|
LL | use AffixHeart::Set;
|
LL | use CauseToBe::Set;
|
LL | use Determine::Set;
|
LL | use PutDown::Set;
|
Bring attention to suggestions when the only difference is capitalization
2019-10-13 23:48:39 -05:00
and 3 other candidates
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
error: aborting due to 2 previous errors
hide `--explain` hint if error has no extended info
2019-04-17 12:26:38 -05:00
Some errors have detailed explanations: E0412, E0425.
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
For more information about an error, try `rustc --explain E0412`.
Reference in New Issue Copy Permalink