Inconsistent path resolution between 'use' and expressions in 2018

[brson]

I don't know the details of "path clarity" and "uniform paths", but I would expect that path resolution in use statements and expressions would work the same. And they do in all situations I've tested except for these two involving external crates:

#![allow(warnings)]
extern crate tokio;

mod a {
    mod tokio { pub mod prelude {
        pub enum Async { NotReady, BlahBlahBlah }
        pub struct NotInTokio;
    } }
    
    // root takes precedence in 2015;
    // ambiguous in 2018, and with uniform_paths
    // use tokio::prelude::Async;
    // failed root resolution in 2015;
    // ambiguous in 2018, and with uniform_paths
    // use tokio::prelude::NotInTokio;
    
    fn f() {
        // _local scope_ takes precedence in 2015, 2018, uniform_paths;
        // inconsistent with 'use' in 2018
        let _ = tokio::prelude::Async::NotReady;
        // local scope in all versions, inconsistent like above
        let _ = tokio::prelude::NotInTokio;
    }
}

The two use statements are ambiguous in 2018, but the two expressions resolve to the local module. I'd expect the expressions to be ambiguous.

Tested in 1.32 and whatever nightly is on playground today.

Playground

[brson]

I tested this with and without the uniform_paths feature but have since been told that uniform_paths is stable, contrary to the edition guide.

[brson]

Here are my local test cases for 2018 paths fwiw https://github.com/brson/advanced-experiments/blob/master/src/bin/paths.rs

[petrochenkov]

@brson

I would expect that path resolution in use statements and expressions would work the same.

The important clarification is that resolution works the same if there are no errors.
Paths in use can produce extra errors compared to non-use paths.
use tokio in the example is one of those extra errors (namely, an ambiguity error).

The good news is this specific error is not technically necessary, but rather introduced for ideological reasons ("ambiguity is bad"), and it can be removed making import paths closer to other paths.
The tracking issue for this ambiguity removal is #56414.

[petrochenkov]

(Some "true" errors exist as well, e.g. you certainly cannot use paths to associated items in imports.)

[brson]

Thanks for the clarifications @petrochenkov. Is there any actual bug here or should this be closed?

[petrochenkov]

No rustc bug, some missing documentation in the edition-guide or reference perhaps.