#[feature(uniform_paths)]: allow `use x::y;` to resolve through `self::x`, not just `::x`.
_Branch originally by @cramertj, based on @petrochenkov's [description on the internals forum](https://internals.rust-lang.org/t/relative-paths-in-rust-2018/7883/30?u=petrochenkov)._
_(note, however, that the approach has significantly changed since)_
Implements `#[feature(uniform_paths)]` from #53130, by treating unqualified `use` paths as maybe-relative. That is, `use x::y;`, where `x` is a plain identifier (not a keyword), is no longer the same as `use :❌:y;`, and before picking an external crate named `x`, it first looks for an item named `x` in the same module (i.e. `self::x`) and prefers that local item instead.
Such a "maybe-relative" `x` can only resolve to an external crate if it's listed in "`extern_prelude`" (i.e. `core` / `std` and all the crates passed to `--extern`; the latter includes Cargo dependencies) - this is the same condition as being able to refer to the external crate from an unqualified, non-`use` path.
All other crates must be explicitly imported with an absolute path, e.g. `use :❌:y;`
To detect an ambiguity between the external crate and the local item with the same name, a "canary" import (e.g. `use self::x as _;`), tagged with the `is_uniform_paths_canary` flag, is injected. As the initial implementation is not sophisticated enough to handle all possible ways in which `self::x` could appear (e.g. from macro expansion), this also guards against accidentally picking the external crate, when it might actually get "shadowed" later.
Also, more canaries are injected for each block scope around the `use`, as `self::x` cannot resolve to any items named `x` in those scopes, but non-`use` paths can, and that could be confusing or even backwards-incompatible.
Errors are emitted only if the main "canary" import succeeds while an external crate exists (or if any of the block-scoped ones succeed at all), and ambiguities have custom error reporting, e.g.:
```rust
#![feature(uniform_paths)]
pub mod foo {
use std::io;
pub mod std { pub mod io {} }
}
```
```rust
error: import from `std` is ambiguous
--> test.rs:3:9
|
3 | use std::io;
| ^^^ could refer to external crate `::std`
4 | pub mod std { pub mod io {} }
| ----------------------------- could also refer to `self::std`
|
= help: write `::std` or `self::std` explicitly instead
= note: relative `use` paths enabled by `#![feature(uniform_paths)]`
```
Another example, this time with a block-scoped item shadowing a module-scoped one:
```rust
#![feature(uniform_paths)]
enum Foo { A, B }
fn main() {
enum Foo {}
use Foo::*;
}
```
```rust
error: import from `Foo` is ambiguous
--> test.rs:5:9
|
4 | enum Foo {}
| ----------- shadowed by block-scoped `Foo`
5 | use Foo::*;
| ^^^
|
= help: write `::Foo` or `self::Foo` explicitly instead
= note: relative `use` paths enabled by `#![feature(uniform_paths)]`
```
Additionally, this PR, because replacing "the `finalize_import` hack" was a blocker:
* fixes #52140
* fixes #52141
* fixes #52705
cc @aturon @joshtriplett
alexcrichton
added
the
A-rust-2018-preview
label
Mark-Simulacrum
added this to the Rust 2018 RC milestone
petrochenkov
referenced this issue
durka commentedJul 25, 2018
You can
usethe current module, even without starting the path withcrate::, and this can shadow extern crates.Cargo.toml:
src/main.rs:
src/png.rs:
This produces the error:
(Note that it did not say "can't find
png_ext". There was speculation on IRC that theusestatement shouldn't have madepng_extavailable for starting paths, onlyself::png_ext.)Further details that point to what's really going on:
self::png_ext::DecodingErrorhas no effectpngresolves the erroruseline touse crate::png as png_ext;has no effectDecodingErrorresolves the errorSo 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!