flaky "access to extern crates through prelude" (for crate std)

[SillyFreak]

I stumbled across this while defining a Result alias. Consider the following code:

pub type Result<T> = std::result::Result<T, ()>;

pub mod example1 {
    use std::result::Result as StdResult;

    pub type Result<T> = StdResult<T, ()>;
}

pub mod example2 {
    pub type Result<T> = std::result::Result<T, ()>;
}

The first two work, while it turns out that for the third definition, I'd need to write ::std::result::Result. The error is this:

error[E0658]: access to extern crates through prelude is experimental (see issue #44660)
  --> example/src/lib.rs:10:26
   |
10 |     pub type Result<T> = std::result::Result<T, ()>;
   |                          ^^^
   |
   = help: add #![feature(extern_prelude)] to the crate attributes to enable

I'm not sure what difference the compiler sees in the access variants, but the fix was not to activate an experimental feature. If the behavior is intended, maybe add the option to use an absolute reference to the hints?

$ rustc --version --verbose
rustc 1.28.0-nightly (5205ae8bd 2018-06-13)
binary: rustc
commit-hash: 5205ae8bdc2991eecf3bfbb58ed8f56c0673e738
commit-date: 2018-06-13
host: x86_64-unknown-linux-gnu
release: 1.28.0-nightly
LLVM version: 6.0

[sfackler]

I've seen this pop up as well.

[nbigaouette-eai]

I'm seeing this error on stable (v.1.27.2) as well when defining a macro to implement methods and access a crate's type.

use uuid;

macro_rules! base_methods {
    () => {
        fn id(&self) -> &uuid::Uuid {
            &self.base.id
        }
    };
}

I need to use &::uuid::Uuid for the compiler to accept the code.

[felixrabe]

The first example given works fine for me:

pub type Result<T> = std::result::Result<T, ()>;

pub mod example1 {
    use std::result::Result as StdResult;

    pub type Result<T> = StdResult<T, ()>;
}

pub mod example2 {
    pub type Result<T> = std::result::Result<T, ()>;
}

Versions checked (on macOS 10.13):

cargo 1.35.0 (6f3e9c367 2019-04-04)
cargo 1.37.0-nightly (545f35425 2019-05-23)

Is this issue still open? Also, #44660 mentioned in the given error message was closed in Aug 2018.

[petrochenkov]

Yeah, the feature was stabilized for both editions somewhere in the end of 2018.