Make macro scope a real name scope and fix some details

[oxalica]

This PR make macro's module scope a real name scope in PerNs, instead of handling Either<PerNs, MacroDef> everywhere.

In rustc, the macro scope behave exactly the same as type and value scope.
It is valid that macros, types and values having exact the same name, and a use statement will import all of them. This happened to module alloc::vec and macro alloc::vec!.
So Either is not suitable here.

There is a trap that not only does #[macro_use] import all #[macro_export] macro_rules, but also imports all macros used in the crate root.
In other words, it just imports all macros in the module scope of crate root. (Visibility of use doesn't matter.)

And it also happened to libstd which has use alloc_crate::vec; in crate root to re-export alloc::vec, which it both a module and a macro.
The current implementation of #[macro_use] extern crate doesn't work here, so that is why only macros directly from libstd like dbg! work, while vec! from liballoc doesn't.
This PR fixes this.

Another point is that, after some tests, I figure out that macro_rules does NOT define macro in current module scope at all.
It defines itself in legacy textual scope. And if #[macro_export] is given, it also is defined ONLY in module scope of crate root. (Then being macro_used, as mentioned above)
(Well, the nightly Declarative Macro 2.0 simply always define in current module scope only, just like normal items do. But it is not yet supported by us)

After this PR, in my test, all non-builtin macros are resolved now. (Hover text for documentation is available) So it fixes #1688 . Since compiler builtin macros are marked as #[rustc_doc_only_macro] instead of #[macro_export], we can simply tweak the condition to let it resolved, but it may cause expansion error.

Some critical notes are also given in doc-comments.

[matklad]

This PR make macro's module scope a real name scope in PerNs, instead of handling Either<PerNs, MacroDef> everywhere.

Hm, interesting! So, the original motivation for handing macros separately was that macros are only needed in the initial expansion phase. After that, the rest of the hir should assume a fully macro expanded code, and, for example, name resolution operations should be forbidden from returning a macro. However, I think that this reasoning is actually flawed: the main thing that tries to resolve paths is name resolution and macro expansion itself! Basically the rest of the hir should see paths already resolved.

[matklad]

bors r+

[bors]

Build succeeded

• continuous-integration/travis-ci/push