Skip to content
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

Closed
troiganto opened this issue Nov 17, 2018 · 1 comment
Closed
Labels
A-diagnostics Area: Messages for errors, warnings, and lints

Comments

@troiganto
Copy link

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:

fn foo() -> None {}

gives the following error on the playground:

error[E0573]: expected type, found variant `None`
 --> src/lib.rs:1:13
  |
1 | fn foo() -> None {}
  |             ^^^^ not a type
  |
  = help: there is an enum variant `bitflags::_core::prelude::v1::None`, try using `bitflags::_core::prelude::v1`?
  = help: there is an enum variant `bitflags::_core::prelude::v1::Option::None`, try using `bitflags::_core::prelude::v1::Option`?
  = help: there is an enum variant `chrono::LocalResult::None`, try using `chrono::LocalResult`?
  = help: there is an enum variant `chrono::format::Pad::None`, try using `chrono::format::Pad`?
  = help: there is an enum variant `clap::Format::None`, try using `clap::Format`?
  = help: there is an enum variant `core::prelude::v1::None`, try using `core::prelude::v1`?
  = help: there is an enum variant `core::prelude::v1::Option::None`, try using `core::prelude::v1::Option`?
  = help: there is an enum variant `csv::Trim::None`, try using `csv::Trim`?
  = help: there is an enum variant `flate2::FlushCompress::None`, try using `flate2::FlushCompress`?
  = help: there is an enum variant `flate2::FlushDecompress::None`, try using `flate2::FlushDecompress`?
  = help: there is an enum variant `libflate::lz77::CompressionLevel::None`, try using `libflate::lz77::CompressionLevel`?
  = help: there is an enum variant `lzw::Bits::None`, try using `lzw::Bits`?
  = help: there is an enum variant `miniz_oxide::MZFlush::None`, try using `miniz_oxide::MZFlush`?
  = help: there is an enum variant `miniz_oxide::deflate::core::TDEFLFlush::None`, try using `miniz_oxide::deflate::core::TDEFLFlush`?
  = help: there is an enum variant `proc_macro2::Delimiter::None`, try using `proc_macro2::Delimiter`?
  = help: there is an enum variant `quote::__rt::Delimiter::None`, try using `quote::__rt::Delimiter`?
  = help: there is an enum variant `serde::export::None`, try using `serde::export`?
  = help: there is an enum variant `serde::export::Option::None`, try using `serde::export::Option`?
  = help: there is an enum variant `serde::private::de::Content::None`, try using `serde::private::de::Content`?
  = help: there is an enum variant `serde_derive_internals::attr::Default::None`, try using `serde_derive_internals::attr::Default`?
  = help: there is an enum variant `serde_derive_internals::attr::EnumTag::None`, try using `serde_derive_internals::attr::EnumTag`?
  = help: there is an enum variant `serde_derive_internals::attr::RenameRule::None`, try using `serde_derive_internals::attr::RenameRule`?
  = help: there is an enum variant `std::prelude::v1::None`, try using `std::prelude::v1`?
  = help: there is an enum variant `std::prelude::v1::Option::None`, try using `std::prelude::v1::Option`?
  = help: there is an enum variant `syn::FloatSuffix::None`, try using `syn::FloatSuffix`?
  = help: there is an enum variant `syn::IntSuffix::None`, try using `syn::IntSuffix`?
  = help: there is an enum variant `syn::PathArguments::None`, try using `syn::PathArguments`?
  = help: there is an enum variant `syn::TraitBoundModifier::None`, try using `syn::TraitBoundModifier`?
  = help: there is an enum variant `syn::export::None`, try using `syn::export`?
  = help: there is an enum variant `syn::export::quote::__rt::Delimiter::None`, try using `syn::export::quote::__rt::Delimiter`?
  = help: there is an enum variant `syntex_syntax::ast::TraitBoundModifier::None`, try using `syntex_syntax::ast::TraitBoundModifier`?
  = help: there is an enum variant `syntex_syntax::attr::InlineAttr::None`, try using `syntex_syntax::attr::InlineAttr`?
  = help: there is an enum variant `syntex_syntax::entry::EntryPointType::None`, try using `syntex_syntax::entry::EntryPointType`?
  = help: there is an enum variant `syntex_syntax::util::parser::Fixity::None`, try using `syntex_syntax::util::parser::Fixity`?
  = help: there is an enum variant `tiff::decoder::CompressionMethod::None`, try using `tiff::decoder::CompressionMethod`?

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.

@memoryruins memoryruins added the A-diagnostics Area: Messages for errors, warnings, and lints label Nov 17, 2018
@zackmdavis
Copy link
Member

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
Labels
A-diagnostics Area: Messages for errors, warnings, and lints
Projects
None yet
Development

No branches or pull requests

3 participants