Skip to content

Glob importing causes unrelated compiler error #19179

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
dylanmckay opened this issue Nov 21, 2014 · 7 comments
Closed

Glob importing causes unrelated compiler error #19179

dylanmckay opened this issue Nov 21, 2014 · 7 comments
Labels
A-resolve Area: Name/path resolution done by `rustc_resolve` specifically

Comments

@dylanmckay
Copy link
Contributor

When using globs to import everything from a module where the module itself imports things from the global namespace causes an error:

error: unresolved import
...
error: unresolved import (maybe you meant `std::*`?)

That is to say, if some_mod.rs glob imports other_mod and other_mod imports something from :: (say, std), the module cannot be found. If the glob import is replaced by manually importing every type, compilation succeeds.

The error occurs on the line in the imported module that tries to import the module.

Test Case (link to Playpen):

#![feature(globs)]

// Import everything from `test_module`
// This causes an error.
use self::test_module::*;

// Import what we want from `test_module`
// This succeeds.
// TODO: uncomment this line
//use self::test_module::Dummy;


mod test_module
{
    // Fails on this line, but only if `test_module` is glob imported.
    // Compilation is successful if globs are not used.
    use std;

    pub struct Dummy;
}

fn main() { }

Several months ago when I started learning Rust, this was actually the error that made modules so confusing to me in the beginning - I couldn't understand why sometimes (apparently when I used globs) I couldn't import std but instead I had to import every function and trait I wanted to use into my module's namespace.

@jdm jdm added A-resolve Area: Name/path resolution done by `rustc_resolve` specifically I-papercut labels Nov 21, 2014
@nrc
Copy link
Member

nrc commented Dec 29, 2014

Interestingly, the use std; doesn't even have to be in the submodule

#![feature(globs)]
use std;
use self::test_module::*;
mod test_module {}

fn main() { }

Gives the same error, but commenting out use self::test_module::*; gives a conflict error for std instead (which I think is correct).

@jpernst
Copy link

jpernst commented Jan 9, 2015

I've been hitting this bug recently as well. Globs seem to interact strangely with non-public use statements. After some more experimentation I've reduced my situation to this:

pub mod a {
    pub use self::aa::*;

    pub mod aa {
        use b::YY; // comment out this...

        pub struct XX;
    }
}

pub mod b {
    pub use self::bb::*;

    pub mod bb {
        use a::XX; // ...or this

        pub struct YY;
    }
}

If either of the marked 'use' lines are commented out, it will compile, but will fail with unresolved import errors if both are present. If the globs are replaced by named imports, it compiles fine.
rustc version:

rustc 1.0.0-nightly (ea6f65c5f 2015-01-06 19:47:08 +0000)
binary: rustc
commit-hash: ea6f65c5f1a3f84e010d2cef02a0160804e9567a
commit-date: 2015-01-06 19:47:08 +0000
host: x86_64-unknown-linux-gnu
release: 1.0.0-nightly

@nrc nrc removed the I-papercut label Jan 11, 2015
@Marckvdv
Copy link

I might have found another variant of this error:

pub mod a {
    use ::b::B;
    use std::*;
    pub struct A {
        i: isize
    }
}
pub mod b {
    use ::a::A;
    use std::*;
    pub struct B {
        i: isize
    }
}

@alexcrichton
Copy link
Member

This has since been fixed, yay!

@gkoz
Copy link
Contributor

gkoz commented Aug 17, 2015

As it doesn't seem to be fixed in beta (at least the one on play.rlo), the earliest release to get the fix would be 1.4?

@alexcrichton
Copy link
Member

Yeah I think this landed relatively recently on nightly, so it should make its way into 1.4

@eddyb
Copy link
Member

eddyb commented Aug 17, 2015

Is this the cyclic globs issue? Does this mean we can finally clean up the import mess in rustc_trans?

lnicola pushed a commit to lnicola/rust that referenced this issue Feb 24, 2025
Ignore assists with many results if grouping not supported
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-resolve Area: Name/path resolution done by `rustc_resolve` specifically
Projects
None yet
Development

No branches or pull requests

8 participants