-
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
Unhelpful error message for missing crate
in uses import
#56821
Labels
A-diagnostics
Area: Messages for errors, warnings, and lints
Comments
It's likely that "uniform paths" will be stabilized for Rust 1.32 (#56417), in that case the code will simply become accepted on stable, obviating the need in extra diagnostics. |
Ok. Then I leave this issue open, until the final word is spoken about "uniform paths". |
bors
added a commit
that referenced
this issue
Jan 12, 2019
Stabilize `uniform_paths` Address all the things described in #56417. Assign visibilities to `macro_rules` items - `pub` to `macro_export`-ed macros and `pub(crate)` to non-exported macros, these visibilities determine how far these macros can be reexported with `use`. Prohibit use of reexported inert attributes and "tool modules", after renaming (e.g. `use inline as imported_inline`) their respective tools and even compiler passes won't be able to recognize and properly check them. Also turn use of uniform paths in 2015 macros into an error, I'd prefer to neither remove nor stabilize them right away because I still want to make some experiments in this area (uniform path fallback was added to 2015 macros used on 2018 edition in #56053 (comment)). UPDATE: The last commit also stabilizes the feature `uniform_paths`. Closes #53130 Closes #55618 Closes #56326 Closes #56398 Closes #56417 Closes #56821 Closes #57252 Closes #57422
bors
added a commit
that referenced
this issue
Jan 12, 2019
Stabilize `uniform_paths` Address all the things described in #56417. Assign visibilities to `macro_rules` items - `pub` to `macro_export`-ed macros and `pub(crate)` to non-exported macros, these visibilities determine how far these macros can be reexported with `use`. Prohibit use of reexported inert attributes and "tool modules", after renaming (e.g. `use inline as imported_inline`) their respective tools and even compiler passes won't be able to recognize and properly check them. Also turn use of uniform paths in 2015 macros into an error, I'd prefer to neither remove nor stabilize them right away because I still want to make some experiments in this area (uniform path fallback was added to 2015 macros used on 2018 edition in #56053 (comment)). UPDATE: The last commit also stabilizes the feature `uniform_paths`. Closes #53130 Closes #55618 Closes #56326 Closes #56398 Closes #56417 Closes #56821 Closes #57252 Closes #57422
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This problem occurs with the new path rules in edition 2018. If the
crate
keyword from a uses import is missing, the current error message is not very helpful. For example:returns on stable, beta and nightly the following error message:
The compiler looks for a crate
bla
but doesn't find one, therefore the error message. I'm not sure, how this relates to the upcoming decision regarding the efforts for path clarity. But I stumbled over this several times now, out of habit...(If this issue is accepted, I would like to improve it :) I would probably need mentoring though.)
The text was updated successfully, but these errors were encountered: