-
Notifications
You must be signed in to change notification settings - Fork 13.4k
f32 seen as ambiguous associated type #26760
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
You're using the type |
Yes, I probably haven't made myself very clear in the description above. |
That's true. The message should read something like "no associated type |
Rustc is underlining all of |
Triage, with the new errors:
ouch 😦 |
The consts in the number type modules should probably be moved to associated constants. I believe we're mostly on board with this, but there's not currently an issue to my knowledge. |
I'm running into this error, this is quite ridiculous to have so much troubles just to use PI. |
I ran into this today. I was reading the docs for Of course, the examples also It would probably be best if there were not two different things named |
At a minimum, the |
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.
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.
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.
can anyone guide me in this |
105 | let v_02 = ::create_vehicle{ |
see http://stackoverflow.com/questions/31208465/pi-constant-is-ambiguous
fails to compile with:
on rust 1.0 stable and 1.1 stable
using the full path
std::f32::consts::PI;
works. The compilation error looks wrong (why is f32 an associated type)?The text was updated successfully, but these errors were encountered: