Uh oh!
There was an error while loading. Please reload this page.
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.
Uh oh!
There was an error while loading. Please reload this page.
estebank
left a comment
There was a problem hiding this comment.
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.
Uh oh!
There was an error while loading. Please reload this page.
davidtwco
commented
Apr 10, 2019
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. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
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.
estebank
commented
Apr 12, 2019
r=me once travis finishes |
estebank
commented
Apr 12, 2019
@bors r+ |
bors
commented
Apr 12, 2019
📌 Commit 5158063 has been approved by |
Suggest importing macros from the crate root Fixesrust-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 Fixesrust-lang#59764. r? @estebank cc @varkor
Suggest importing macros from the crate root Fixesrust-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