2018: current module shadows crate in use statement

[durka]

You can use the current module, even without starting the path with crate::, and this can shadow extern crates.

Cargo.toml:

cargo-features = ["edition"]

[package]
edition = "2018"
name = "xyz"
version = "0.1.0"
authors = ["Alex Burka <aburka@seas.upenn.edu>"]

[dependencies]
png = "0.12.0"

src/main.rs:

#![feature(rust_2018_preview)]

mod png;

fn main() {
    println!("Hello, world!");
}

src/png.rs:

use png as png_ext;

fn foo() -> png_ext::DecodingError { unimplemented!() }

This produces the error:

error[E0412]: cannot find type `DecodingError` in module `png_ext`
 --> src/png.rs:3:22
  |
3 | fn foo() -> png_ext::DecodingError { panic!() }
  |                      ^^^^^^^^^^^^^ not found in `png_ext`

(Note that it did not say "can't find png_ext". There was speculation on IRC that the use statement shouldn't have made png_ext available for starting paths, only self::png_ext.)

Further details that point to what's really going on:

• Changing line 3 to self::png_ext::DecodingError has no effect
• Renaming the module to anything but png resolves the error
• Changing the use line to use crate::png as png_ext; has no effect
• Adding a type to the module called DecodingError resolves the error

So we have a module importing itself, even though it didn't use a crate:: path, and shadowing a crate. This is not one of the features we should be borrowing from the Python module system!

[petrochenkov]

Sigh, single segment imports (use ident [as something], but not use ident::ident::...) use some special hack in fn finalize_import to implement feature(extern_absolute_paths) due to some deficiencies in import resolution infrastructure.
Apparently that hack doesn't always work correctly (namely, in presence of module with the same name), this wasn't supposed to happen.