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

Error message suggests using core when it ought to suggest using std #23355

Closed
bstrie opened this issue Mar 14, 2015 · 6 comments · Fixed by #32439
Closed

Error message suggests using core when it ought to suggest using std #23355

bstrie opened this issue Mar 14, 2015 · 6 comments · Fixed by #32439
Labels
A-diagnostics Area: Messages for errors, warnings, and lints

Comments

@bstrie
Copy link
Contributor

bstrie commented Mar 14, 2015

Program:

fn main() {
    Vec::from_iter();
}

Output:

fri.rs:2:5: 2:19 error: type `collections::vec::Vec<_>` does not implement any method in scope named `from_iter`
fri.rs:2     Vec::from_iter();
             ^~~~~~~~~~~~~~
fri.rs:2:19: 2:19 help: methods from traits can only be called if the trait is in scope; the following trait is implemented but not in scope, perhaps add a `use` for it:
fri.rs:2:19: 2:19 help: candidate #1: use `core::iter::FromIterator`
error: aborting due to previous error

Note that it suggests core::iter::FromIterator when it could be suggesting std::iter::FromIterator. Should a user follow this advice, they would need to also link libcore via extern crate core, which (IIRC) means that they will be opting out of 1.0-stable thanks to core's intentional lack of stability.

I don't know if it's worth nominating, but this is definitely a backcompat hazard for users.

@bstrie bstrie added the A-diagnostics Area: Messages for errors, warnings, and lints label Mar 14, 2015
@ghost
Copy link

ghost commented Mar 14, 2015

Tempted to close this as a dupe of #23224.

@bstrie
Copy link
Contributor Author

bstrie commented Nov 28, 2015

I think it's worth keeping this open as a more specific example of #23224, because it specifically has implications for stabilizing libcore. I can imagine a short-term hack to resolve this specific issue that would leave #23224 and #13065 for later.

@arielb1
Copy link
Contributor

arielb1 commented Nov 28, 2015

@bstrie

Such a hack will probably not be implemented.

@bstrie
Copy link
Contributor Author

bstrie commented Nov 29, 2015

@arielb1 I as well don't think it's likely, merely a possibility. :P

I also think this is a much bigger pain point for beginners than most people realize. The only reason why I'm suggesting an ugly hack at all is because this must be addressed before libcore hits stable, and its FCP will be coming to a close any day now.

@arielb1
Copy link
Contributor

arielb1 commented Nov 29, 2015

@bstrie

Why does this need to be addressed?

@bstrie
Copy link
Contributor Author

bstrie commented Dec 2, 2015

@arielb1 I was under the impression that using any API from core directly required a feature flag and hence was only possible on nightly, but I've just experimented and determined that's not the case. So I suppose stabilizing core at this point won't make us any worse off regarding this issue.

bors added a commit that referenced this issue Mar 31, 2016
diagnostics: make paths to external items more visible

This PR changes the reported path for an external item so that it is visible from at least one local module (i.e. it does not use any inaccessible external modules) if possible. If the external item's crate was declared with an `extern crate`, the path is guarenteed to use the `extern crate`.

Fixes #23224, fixes #23355, fixes #26635, fixes #27165.

r? @nrc
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

Successfully merging a pull request may close this issue.

2 participants