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

Use unqualified names in type errors when possible #19792

Closed
kmcallister opened this issue Dec 13, 2014 · 4 comments
Closed

Use unqualified names in type errors when possible #19792

kmcallister opened this issue Dec 13, 2014 · 4 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@kmcallister
Copy link
Contributor

error: mismatched types: expected core::option::Option<alloc::arc::Arc<std::collections ::hash::map::HashMap<&'static str, alloc::arc::Arc<collections::vec::Vec<item::Item>>>>>,
found core::option::Option<alloc::arc::Arc<std::collections::hash::map::HashMap<&str, alloc::arc::Arc<collections::vec::Vec<&generator::Job>>>>>

would be much more readable as

error: mismatched types: expected Option<Arc<HashMap<&'static str, Arc<Vec<Item>>>>>,
found Option<Arc<HashMap<&str, Arc<Vec<&Job>>>>>

One possibility is to use the names in scope where the type error appears. In any event, we should make sure none of the unqualified names in a given error are ambiguous.

@kmcallister kmcallister added the A-diagnostics Area: Messages for errors, warnings, and lints label Dec 13, 2014
@barosl
Copy link
Contributor

barosl commented Dec 13, 2014

What if the user imports a name using as? (e.g. use std::io::fs::File as Phile) Should the error message be displayed with the changed name, or the original name?

@kmcallister
Copy link
Contributor Author

I'm not sure. There are a few options:

  1. Use the local name
  2. Use the local name, and put a note: on the renaming import
  3. Use the unqualified original name
  4. Use the full path

I think (1) and (3) are too ambiguous. My preference is (2). But something like this is still unacceptable:

foo.rs:2:1: error: mismatched types: expected `Foo`, found `Foo`
foo.rs:1:1: note: `baz::Bar` imported as `Foo`

If two distinct types would have the same unqualified name in a given error message, at least one of them must be printed qualified.

Actually, do we want this to hold over the entirety of type errors printed by rustc in a given run?

@steveklabnik
Copy link
Member

Triage: no change.

@steveklabnik steveklabnik added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Mar 9, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 22, 2017
@estebank
Copy link
Contributor

estebank commented Sep 21, 2017

Duplicate of #21934

@estebank estebank marked this as a duplicate of #19792 Sep 21, 2017
@estebank estebank marked this as a duplicate of #21934 Sep 21, 2017
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 C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants