-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Too many help messages on error "[E0573]: expected type, found variant None
"
#56028
Labels
A-diagnostics
Area: Messages for errors, warnings, and lints
Comments
memoryruins
added
the
A-diagnostics
Area: Messages for errors, warnings, and lints
label
Nov 17, 2018
I think I have a solution, but let me sleep on it before filing a pull-request. (Want to scrutinize the test output some more, and as a driveby, special-case enums from the prelude, which are getting reported twice as of today.) |
zackmdavis
added a commit
to zackmdavis/rust
that referenced
this issue
Dec 23, 2018
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 rust-lang#56028. In the matter of message wording, "you can" is redundant (and perhaps too informal); prefer the imperative.
Centril
added a commit
to Centril/rust
that referenced
this issue
Dec 23, 2018
…dtwco enum type instead of variant suggestion unification Fixes rust-lang#56028. 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 rust-lang#56028. In the matter of message wording, "you can" is redundant (and perhaps too informal); prefer the imperative. In a second commit, we do some unprincipled special-casing to correct and beautify suggestions for `Option` and `Result` (where the existing code was being confused by their being reexported in the prelude). r? @davidtwco
Centril
added a commit
to Centril/rust
that referenced
this issue
Dec 23, 2018
…dtwco enum type instead of variant suggestion unification Fixes rust-lang#56028. 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 rust-lang#56028. In the matter of message wording, "you can" is redundant (and perhaps too informal); prefer the imperative. In a second commit, we do some unprincipled special-casing to correct and beautify suggestions for `Option` and `Result` (where the existing code was being confused by their being reexported in the prelude). r? @davidtwco
Centril
added a commit
to Centril/rust
that referenced
this issue
Dec 23, 2018
…dtwco enum type instead of variant suggestion unification Fixes rust-lang#56028. 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 rust-lang#56028. In the matter of message wording, "you can" is redundant (and perhaps too informal); prefer the imperative. In a second commit, we do some unprincipled special-casing to correct and beautify suggestions for `Option` and `Result` (where the existing code was being confused by their being reexported in the prelude). r? @davidtwco
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When specifying a an enum variant where a type is expected, rustc gives a list of all possible variants with that name. (and suggests to use the enum type instead)
In projects with a lot of dependencies and a very common variant name, this list can quickly become overwhelming. This is e.g. the case on the Rust Playground on the 2018 edition, since all whitelisted crates get linked into the playground code.
This minimal example:
gives the following error on the playground:
Maybe a better approach is to only give
N
suggestions by default, and show the full list when--verbose
is passed.Rust version is 1.31.0-beta.13, edition is 2018.
The text was updated successfully, but these errors were encountered: