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

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.

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

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

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.

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

This is still an issue.

@Blei

@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.

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

revised Priority to P-low

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::*;
}

Work around rust-lang/rust#4865

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

Re-nominating because of that

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.

I reached this point while reducing an issue, I think it is the same problem, and the testcase is somewhat simpler.

pub mod a {
  use b::*;
}

pub mod b {
  use a::*;
}

use a::*;

fn main() {
}

Still apply. Spend two days getting mad because of this bug. Note that there is no need for the modules to reference each others directly :

pub mod a {
    use b::fn_b;
    use c::*;

    pub fn fn_a(){
    }
}

pub mod b {
    use a::fn_a;
    use c::*;

    pub fn fn_b(){
    }
}

pub mod c{
    pub fn fn_c(){
    }
}

use a::fn_a;
use b::fn_b;

fn main() {
}

Here the star imports (mod::*) are not the modules themself, but another module, the module c.

@gbersac

@gbersac 's test case seems especially frustrating; as he noted, the reported error is for imports that are not glob imports, and yet for some reason the presence of the unrelated glob imports is causing the resolution of the circular non-glob imports to fail.

The final case here is solved by #26242

Adjusting help message (rust-lang#4865)

Merge pull request rust-lang#4865 from rust-lang/rustup-2026-02-19

Extern fns are implicitly unsafe

Navigation Menu

Repository navigation

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

4 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

catamorphism commented on Apr 25, 2013

graydon commented on May 2, 2013

Blei commented on Jul 9, 2013

Blei commented on Jul 9, 2013

thestinger commented on Aug 27, 2013

alexcrichton commented on Oct 11, 2013

pcwalton commented on Nov 22, 2013

pnkfelix commented on Dec 19, 2013

emberian commented on Jul 31, 2014

steveklabnik commented on Feb 11, 2015

steveklabnik commented on Feb 11, 2015

pnkfelix commented on Feb 12, 2015

4 remaining items

kali commented on May 3, 2015

gbersac commented on May 3, 2015

pnkfelix commented on May 15, 2015

brson commented on Jun 12, 2015

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions