`use self::b` has stopped consulting local non-pub `use` of `b`

[pnkfelix]

I used to be able to do:

use a::b;
use D = self::b::C;

but now I cannot, at least not in all cases.

Here is a test case:

mod a {
    pub mod b {
        pub type C = uint;
    }
}

#[cfg(variant1)]
mod variant1 {
    use a::b;
    use D = self::b::C;

    pub fn main() {
        let d : D = 3;
        println!("d: {}", d);
    }
}

#[cfg(variant2)]
mod variant2 {
    use D = a::b::C;

    pub fn main() {
        let d : D = 3;
        println!("d: {}", d);
    }
}

#[cfg(variant1)]
pub fn main() {
    variant1::main();
}

#[cfg(variant2)]
pub fn main() {
    variant2::main();
}

Here is a transcript of how this used to work (on a rustc v0.11-pre circa 2014-04-07) versus breaking now (on a rustc v0.11-pre circa 2014-04018).

% rustc --version
/Users/fklock/opt/rust-dbg/bin/rustc 0.11-pre (0deb16a 2014-04-07 02:26:37 -0700)
host: x86_64-apple-darwin
% rustc --cfg variant1 /tmp/n.rs && ./n
d: 3
% rustc --cfg variant2 /tmp/n.rs && ./n
d: 3
% ./objdir-dbgopt/x86_64-apple-darwin/stage2/bin/rustc --version
./objdir-dbgopt/x86_64-apple-darwin/stage2/bin/rustc 0.11-pre (ce2bab6 2014-04-18 04:11:19 -0700)
host: x86_64-apple-darwin
% ./objdir-dbgopt/x86_64-apple-darwin/stage2/bin/rustc --cfg variant1 /tmp/n.rs && ./n
/tmp/n.rs:10:9: 10:24 error: unresolved import: could not find `b` in `variant1`.
/tmp/n.rs:10     use D = self::b::C;
                     ^~~~~~~~~~~~~~~
/tmp/n.rs:10:9: 10:24 error: failed to resolve import `self::b::C`
/tmp/n.rs:10     use D = self::b::C;
                     ^~~~~~~~~~~~~~~
error: aborting due to 2 previous errors
% ./objdir-dbgopt/x86_64-apple-darwin/stage2/bin/rustc --cfg variant2 /tmp/n.rs && ./n
d: 3
% 

Discussion with @alexcrichton leads me to think that this change may have been injected as part of PR #13409.

It may or may be a bug. Whether you see it as a bug may depend on your view of how privacy and use interact. (In particular, if you make a variant3 of variant1 where the use a::b is rewritten to pub use a::b, so that the b is now publicly exported from self, then things seem to work.)

My reasoning is that we should be able to do:

use a::b; // a non-pub import
use D = self::b::C;

because the way we resolve use self::b::C, we look for other non-pub things in self, such as a hypothetical non-pub mod b defined within self.

[pnkfelix]

Here is a more fully fleshed out illustration of the alternatives I described above:

mod a {
    pub mod b {
        pub type C = uint;
    }
}

#[cfg(variant1)]
mod variant1 {
    use a::b;
    use D = self::b::C;

    pub fn main() {
        let d : D = 3;
        println!("d: {}", d);
    }
}

#[cfg(variant2)]
mod variant2 {
    use D = a::b::C;

    pub fn main() {
        let d : D = 3;
        println!("d: {}", d);
    }
}

#[cfg(variant3)]
mod variant3 {
    pub use a::b;
    use D = self::b::C;

    pub fn main() {
        let d : D = 3;
        println!("d: {}", d);
    }
}

#[cfg(variant4)]
mod variant4 {
    use D = self::b::C;

    pub fn main() {
        let d : D = 3;
        println!("d: {}", d);
    }

    mod b {
        pub type C = uint;
    }
}

#[cfg(variant1)]
pub fn main() {
    variant1::main();
}

#[cfg(variant2)]
pub fn main() {
    variant2::main();
}

#[cfg(variant3)]
pub fn main() {
    variant3::main();
}

#[cfg(variant4)]
pub fn main() {
    variant4::main();
}

The point is that variant4 is meant to illustrate that we allow use D = self::b::C to look at other non-pub locally-visible things named b, so why should we make an exception for use a::b; ?

(There may indeed be good reasons. For example, if we need to impose this restriction to avoid import cycles, I can accept that. But I want to make sure we did not just accidentally regress this feature without consideration.)

[alexcrichton]

If we wanted to restore this behavior, it would also enable something like:

mod a {
    use b::c;

    use self::c::foo;
    use a::c::foo;
}

mod b {
    pub mod c {
        pub fn foo() {}
    }
}

Allowing self::c::foo seems ok, but allowing a::c::foo sits less well with me... Arguably they're the same thing though.

[pnkfelix]

@alexcrichton I guess from my POV, I do not see use a::... as synonymous with use self::...

It makes sense to me that use a::... would be restricted to the public interface of a; from my POV, one would like use a::[STUFF] to have the same meaning at any valid use-decl context within a given crate (i.e. I would like to be able to freely cut and paste such use-decls down into other fns or mods), and that would require restricting use a::... to the public interface of a.

But use self::[STUFF] cannot possibly enjoy the same property. It cannot have the same meaning in other mods within the crate. So it would make sense to me for it to obey different rules about lookup, where it would have access to the non-pub names that have been imported into the current mod.

[flaper87]

Triage:

The syntax use D = a::b::C has been deprecated in favor of use a::b::C as D. However, the problem still exists when using the new syntax. Here's an updated example:

mod a {
    pub mod b {
        pub type C = uint;
    }
}

#[cfg(variant1)]
mod variant1 {
    use a::b;
    use self::b::C as D;

    pub fn main() {
        let d : D = 3;
        println!("d: {}", d);
    }
}

#[cfg(variant2)]
mod variant2 {
    use a::b::C as D;

    pub fn main() {
        let d : D = 3;
        println!("d: {}", d);
    }
}

#[cfg(variant1)]
pub fn main() {
    variant1::main();
}

#[cfg(variant2)]
pub fn main() {
    variant2::main();
}

And the updated output:

phantom /tmp $ rustc --cfg variant1 tests.rs
tests.rs:10:9: 10:24 error: unresolved import `self::b::C`. Could not find `b` in `variant1`
tests.rs:10     use self::b::C as D;
                    ^~~~~~~~~~~~~~~
error: aborting due to previous error
phantom /tmp $ rustc --cfg variant2 tests.rs 

[steveklabnik]

Triage; still reproduces