'unresolved import' after adding '#![feature(proc_macro)]'

[CodeSandwich]

I've found a strange bug related to proc macros, which I have hard time reproducing. The simplest steps are:

1. Clone futures_rs (https://github.com/rust-lang-nursery/futures-rs)
2. Check out version tagged as 0.1.18 (it does not fail on the newest version)
3. Run cargo check - it passes
4. Add #![feature(proc_macro)] on the beginning of src/lib.rs
5. Run cargo check - it fails:

error[E0432]: unresolved import
  --> src/future/mod.rs:34:16
   |
34 | pub use self::{result as done, FutureResult as Done};
   |                ^^^^^^^^^^^^^^

error: aborting due to previous error

I'm sorry for convoluted instructions, I could not reproduce the issue from the scratch or by reducing futures-rs to a failing bare minimum.

The failing code looks really casual, just reexports of a simple function. If anybody could find the root cause, that would probably help a lot.

I'm using rustc 1.27.0-nightly (ac3c2288f 2018-04-18) on Ubuntu 17.10.

[CodeSandwich]

New discovery: changing the offending line 34 in src/future/mod.rs from
pub use self::{result as done, ...
to
pub use self::{result_::result as done, ...
fixes the error

[CodeSandwich]

I've extracted the root cause (Playground):

#![feature(proc_macro)]
use std::result;
mod module {
    pub fn result() {}
}
pub use self::module::result;
pub use self::result as rename;

[petrochenkov]

It's rather caused by use_extern_macros (#35896) that's enabled by proc_macro implicitly.
I can't promise, but I'll try to investigate this issue this weekend.

[petrochenkov]

Intermediate results:

Further minimized reproduction (only local items used, no self, separate modules):

#![feature(use_extern_macros)]

mod type_ns {
    pub type A = u8;
}
mod value_ns {
    pub const A: u8 = 0;
}
mod merge {
    pub use type_ns::A;
    pub use value_ns::A;
}

use merge::A; //~ ERROR unresolved import

Without use_extern_macros imports do not consider macro namespace and fixed-point import resolution runs in two namespaces (type and value).
With use_extern_macros fixed-point import resolution runs in three namespaces (type, value and macro) and for some reason merge::A ends up as indeterminate in macro namespace (instead of supposedly correct "determinate, no resolution"), i.e. the algorithm gets stuck before resolving all imports.

I haven't yet figured out why exactly this happens and this particular case is likely a bug, but it's quite possible that import resolution in 2+1 namespaces can legitimately lead to more errors due to indeterminacy, so it'll certainly need to go through crater before stabilization.