Re-exporting items using a glob breaks if the module imports another module

[z0w0]

priv mod say {
    pub fn hello() { io::println(~"hello"); }
}

pub mod hello {
    use say;

    pub fn hello() {
        say::hello();
    }
}

pub use hello::*; // doesn't work - `pub use hello::hello;` does

fn main() {
    hello();
}

Results in this error when compiling:

error: failed to resolve imports
a.rs:13:8: 13:17 error: unresolved import
a.rs:13 pub use hello::*; // doesn't work - `pub use hello::hello;` does
                ^~~~~~~~~
a.rs:6:5: 6:9 error: unresolved import
a.rs:6  use say;
            ^~~~

As mentioned in the code, explicitly re-exporting items works but is not a good alternative for when you have hundreds of items (including variants) in a module. Changing the say module to public doesn't fix it.

[catamorphism]

Not critical for 0.7. Nominating for milestone 1, well-defined.

[graydon]

accepted for well defined - promises made by the resolve pass need to be written down

[Blei]

Still applies. Here's the updated source code:

pub use hello::*; // doesn't work - `pub use hello::hello;` does

pub mod say {
    pub fn hello() { println("hello"); }
}

pub mod hello {
    use say;

    pub fn hello() {
        say::hello();
    }
}

fn main() {
    hello();
}

The error is now:

blerg2.rs:1:8: 1:17 error: unresolved import
blerg2.rs:1 pub use hello::*; // doesn't work - `pub use hello::hello;` does
                    ^~~~~~~~~
blerg2.rs:8:8: 8:11 error: unresolved import (maybe you meant `say::*`?)
blerg2.rs:8     use say;
                    ^~~
error: aborting due to 2 previous errors

The error about say goes away when changing the glob to a single import.

[Blei]

And here's a failing cross-crate example that's very probably related, so I thought I'd add it here instead of opening a new issue.

// foo.rs
pub use foo::*;

mod foo {
    pub fn foo() { println("foo"); }
}

// bar.rs
extern mod foo;
use foo::*;

fn main() {
    foo();
}

Compilation:

% rustc --lib foo.rs
warning: missing crate link meta `name`, using `foo` as default
warning: missing crate link meta `vers`, using `0.0` as default
% rustc -L. bar.rs
error: linking with `cc` failed with code 1
note: cc arguments: -L/home/philipp/programming/rust/x86_64-unknown-linux-gnu/stage2/lib/rustc/x86_64-unknown-linux-gnu/lib -m64 -o bar bar.o -L/home/philipp/programming/rust/x86_64-unknown-linux-gnu/stage2/lib/rustc/x86_64-unknown-linux-gnu/lib -lstd-6c65cf4b443341b1-0.8-pre -L. -lfoo-15fb3a718ea23983-0.0 -lrustrt -lrt -lpthread -L. -lrt -ldl -lm -lmorestack -lrustrt -Wl,-rpath,$ORIGIN/../../programming/rust/x86_64-unknown-linux-gnu/stage2/lib/rustc/x86_64-unknown-linux-gnu/lib -Wl,-rpath,$ORIGIN/. -Wl,-rpath,/home/philipp/programming/rust/x86_64-unknown-linux-gnu/stage2/lib/rustc/x86_64-unknown-linux-gnu/lib -Wl,-rpath,/home/philipp/tmp/6477/. -Wl,-rpath,/usr/local/lib/rustc/x86_64-unknown-linux-gnu/lib
note: bar.o: In function `main::_c6c3cd618d2fde1::_0$x2e0':
bar.rc:(.text+0x2c): undefined reference to `foo::foo::_15bec6257b8bff78::_0$x2e0'
collect2: Fehler: ld gab 1 als Ende-Status zurück

error: aborting due to previous error

[thestinger]

This is still an issue.

[alexcrichton]

@Blei, your second test case (which fails with a linker error), I believe was fixed by #9791.

Otherwise I believe that this is another facet of glob imports having circular references causing problems. The imports at the top level of the crate cannot be considered resolved until the glob is resolved, but the glob cannot get resolved until mod hello is resolved. Now this method can't quite get resolved because use say looks up imports in the global module, which is still waiting on being resolved, hence the circular dependency.

This is one of the reasons why globs are currently behind a feature flag. Their behavior is subtle and unexpected in certain ways, along with them not always having the best error messages.

Regardless, leaving open for now as it still reproduces.

[pcwalton]

Globs are feature gated. Nominating to remove from backcompat-lang.

[pnkfelix]

revised Priority to P-low

[emberian]

Another example (stripped down) from gl-rs:

#![crate_type = "lib"]

#![feature(globs)]

extern crate libc;

use std::mem;

use self::types::*;

pub mod types {
    use libc;
}

mod storage {
    use libc;
}

mod failing {
    use libc;
    use super::types::*;
}

[steveklabnik]

Triage: globs are un-feature gated, but this issue still persists.

[steveklabnik]

Re-nominating because of that

[pnkfelix]

polish issue, 1.0 P-high. (Note that we believe this and other glob bugs we know of are "only" rejecting valid programs, and thus the associated bug can be fixed backwards compatibly.)

If someone knows of a case where an invalid program is accepted due to glob bugs, that would be much more severe.