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

Wrong "possible better candidate is found in another module" suggestion #42944

Closed
est31 opened this issue Jun 28, 2017 · 6 comments · Fixed by #58381
Closed

Wrong "possible better candidate is found in another module" suggestion #42944

est31 opened this issue Jun 28, 2017 · 6 comments · Fixed by #58381
Assignees
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-resolve Area: Name resolution A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix` A-visibility Area: Visibility / privacy C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@est31
Copy link
Member

est31 commented Jun 28, 2017

For this code:

mod foo {
    pub struct B(());
}
mod bar {
    use foo::B;
    fn foo() {
        B(());
    }
}

You get the following error message:

error[E0423]: expected function, found struct `B`
 --> <anon>:7:9
  |
7 |         B(());
  |         ^
  |         |
  |         did you mean `B { /* fields */ }`?
  |         constructor is not visible here due to private fields
  |
help: possible better candidate is found in another module, you can import it into scope
  | use foo::B;

The suggestion may be excused to be not 100% perfect, but here it suggests to add an use statement despite that same item being imported already. What I want is this exactly: that it removes stuff from the suggestion list that is already being imported.

Note that changing the glob import to a non glob one doesn't change anything.

@est31
Copy link
Member Author

est31 commented Jun 28, 2017

cc @estebank

@petrochenkov petrochenkov added A-diagnostics Area: Messages for errors, warnings, and lints A-resolve Area: Name resolution A-visibility Area: Visibility / privacy labels Jun 28, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 26, 2017
@oli-obk
Copy link
Contributor

oli-obk commented Aug 10, 2017

Why is that even an error?

@est31
Copy link
Member Author

est31 commented Aug 10, 2017

@oli-obk tuple structs have private fields by default, you can't construct instances of B outside of the foo module.

@oli-obk
Copy link
Contributor

oli-obk commented Aug 10, 2017

oh ^^ maybe we should simply modify this error message then to say that the "function" is private?

@est31
Copy link
Member Author

est31 commented Aug 10, 2017

It already says "constructor is not visible here due to private fields". That's okay, but maybe you might have meant another B from another module or something. However, the candidate offered is not any better as its the same one you are attempting to use.

@est31 est31 closed this as completed Oct 19, 2018
@rust-lang rust-lang locked and limited conversation to collaborators Oct 19, 2018
@estebank
Copy link
Contributor

estebank commented Feb 7, 2019

Reopening to track "removal of suggestion" work for pub tuple structs with private fields.

@estebank estebank reopened this Feb 7, 2019
@estebank estebank added the A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix` label Feb 7, 2019
@davidtwco davidtwco self-assigned this Feb 11, 2019
Centril added a commit to Centril/rust that referenced this issue Feb 13, 2019
Only suggest imports if not imported.

Fixes rust-lang#42944 and fixes rust-lang#53430.

This commit modifies name resolution error reporting so that if a name
is in scope and has been imported then we do not suggest importing it.

This can occur when we add a label about constructors not being visible
due to private fields. In these cases, we know that the struct/variant
has been imported and we should silence any suggestions to import the
struct/variant.

r? @estebank
Centril added a commit to Centril/rust that referenced this issue Feb 13, 2019
Only suggest imports if not imported.

Fixes rust-lang#42944 and fixes rust-lang#53430.

This commit modifies name resolution error reporting so that if a name
is in scope and has been imported then we do not suggest importing it.

This can occur when we add a label about constructors not being visible
due to private fields. In these cases, we know that the struct/variant
has been imported and we should silence any suggestions to import the
struct/variant.

r? @estebank
Centril added a commit to Centril/rust that referenced this issue Feb 13, 2019
Only suggest imports if not imported.

Fixes rust-lang#42944 and fixes rust-lang#53430.

This commit modifies name resolution error reporting so that if a name
is in scope and has been imported then we do not suggest importing it.

This can occur when we add a label about constructors not being visible
due to private fields. In these cases, we know that the struct/variant
has been imported and we should silence any suggestions to import the
struct/variant.

r? @estebank
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-resolve Area: Name resolution A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix` A-visibility Area: Visibility / privacy C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants