-
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
str primitive usage should automatically recommend str module functions #46660
Labels
A-diagnostics
Area: Messages for errors, warnings, and lints
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
Comments
estebank
added
A-diagnostics
Area: Messages for errors, warnings, and lints
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
labels
Dec 12, 2017
Centril
added a commit
to Centril/rust
that referenced
this issue
Apr 19, 2019
Suggest appropriate path when calling associated item on bare types When looking at the documentation for `std::f32` or `std::str`, for example, it is easy to get confused and assume `std::f32` and `f32` are the same thing. Because of this, it is not uncommon to attempt writing `f32::consts::PI` instead of the correct `std::f32::consts::PI`. When encountering the former, which results in an access error due to it being an inexistent path, try to access the same path under `std`. If this succeeds, this information is stored for later tweaking of the final E0599 to provide an appropriate suggestion. Fix rust-lang#26760, fix rust-lang#46660.
Centril
added a commit
to Centril/rust
that referenced
this issue
Apr 19, 2019
Suggest appropriate path when calling associated item on bare types When looking at the documentation for `std::f32` or `std::str`, for example, it is easy to get confused and assume `std::f32` and `f32` are the same thing. Because of this, it is not uncommon to attempt writing `f32::consts::PI` instead of the correct `std::f32::consts::PI`. When encountering the former, which results in an access error due to it being an inexistent path, try to access the same path under `std`. If this succeeds, this information is stored for later tweaking of the final E0599 to provide an appropriate suggestion. Fix rust-lang#26760, fix rust-lang#46660.
Centril
added a commit
to Centril/rust
that referenced
this issue
Apr 19, 2019
Suggest appropriate path when calling associated item on bare types When looking at the documentation for `std::f32` or `std::str`, for example, it is easy to get confused and assume `std::f32` and `f32` are the same thing. Because of this, it is not uncommon to attempt writing `f32::consts::PI` instead of the correct `std::f32::consts::PI`. When encountering the former, which results in an access error due to it being an inexistent path, try to access the same path under `std`. If this succeeds, this information is stored for later tweaking of the final E0599 to provide an appropriate suggestion. Fix rust-lang#26760, fix rust-lang#46660.
Thanks, @estebank! |
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.
Using
str
without thestd::str
prefix to specify the module generates unhelpful error messages (especially since the distinction between thestd::str
module and thestr
primitive is not very nicely thought out due to technical restrictions I wish we could revisit).Example code:
This causes the compiler to emit the following error:
A recommendation to specify
std::
to access the module function with the same name would be most helpful. In fact, anything the compiler could do to blur the distinction between the type and the primitive would be most appreciated.The text was updated successfully, but these errors were encountered: