-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Suggest importing macros from the crate root #59784
Conversation
This commit adds a test demonstrating the current behaviour when a macro defined in a module with the `#[macro_export]` is imported from the module rather than the crate root.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems ok to me, but there's quite a bit of span wrangling here that makes me uneasy (but is sometimes unavoidable). I'll take a closer look at that code later. For now the only complaint I'd have is the separation of the note into 3. Relying on terminal word-wrapping is reasonable in my mind.
I only span-wrangled here because I couldn't see another way in this case. If you can think of an alternative, I'll happily take that approach. While I have introduced some more span-wrangling with this PR, I was able to re-use a bunch of the existing span-wrangling from a previous PR, some of the diff is just extracting that existing logic into functions. |
This commit suggests importing a macro from the root of a crate as the intent may have been to import a macro from the definition location that was annotated with `#[macro_export]`.
This commit extends the suggestion to handle imports that are aliased to another name.
This commit introduces more dirty span manipulation into the compiler in order to handle the various edge cases in moving/renaming the macro import so it is at the root of the import.
This commit removes the assumption that the start of a use statement will always be on one line with a single space - which was silly in the first place.
This commit changes the suggestion so that it is split into multiple parts in an effort to reduce the impact the applied suggestion could have on formatting.
r=me once travis finishes |
@bors r+ |
📌 Commit 5158063 has been approved by |
Suggest importing macros from the crate root Fixes rust-lang#59764. r? @estebank cc @varkor
Rollup of 9 pull requests Successful merges: - rust-lang#59655 (Use a proc macro to declare preallocated symbols) - rust-lang#59769 (compiletest normalization: preserve non-JSON lines such as ICEs) - rust-lang#59776 (Apply resource-suffix to search-index and source-files scripts as well) - rust-lang#59784 (Suggest importing macros from the crate root) - rust-lang#59812 (Exclude profiler-generated symbols from MSVC __imp_-symbol workaround.) - rust-lang#59856 (update polonius-engine) - rust-lang#59874 (Clean up handling of `-Z pgo-gen` commandline option.) - rust-lang#59890 (Don't generate empty json variables) - rust-lang#59911 (Revert "compile crates under test w/ -Zemit-stack-sizes") Failed merges: r? @ghost
Suggest importing macros from the crate root Fixes rust-lang#59764. r? @estebank cc @varkor
Suggest importing macros from the crate root Fixes rust-lang#59764. r? @estebank cc @varkor
Rollup of 6 pull requests Successful merges: - #59776 (Apply resource-suffix to search-index and source-files scripts as well) - #59784 (Suggest importing macros from the crate root) - #59812 (Exclude profiler-generated symbols from MSVC __imp_-symbol workaround.) - #59874 (Clean up handling of `-Z pgo-gen` commandline option.) - #59890 (Don't generate empty json variables) - #59911 (Revert "compile crates under test w/ -Zemit-stack-sizes") Failed merges: r? @ghost
Fixes #59764.
r? @estebank
cc @varkor