circular imports with globs

[jesse99]

Given that a crate is the unit of compilation it seems both silly and annoying to not be able to have modules within a crate use each other.

If, for some reason, this is not fixed then the error message should be. It's currently "failed to resolve imports" which provides essentially no insight into where the problem is. Identifying a circular import given that does not sound like fun at all, especially in a large project where the circular imports could be indirect.

[pcwalton]

This will be fixed with the "use mod foo;" change.
On Sep 2, 2012 1:51 PM, "Jesse Jones" notifications@github.com wrote:

Given that a crate is the unit of compilation it seems both silly and
annoying to not be able to have modules within a crate use each other.

If, for some reason, this is not fixed then the error message should be.
It's currently "failed to resolve imports" which provides essentially no
insight into where the problem is. Identifying a circular import given that
does not sound like fun at all, especially in a large project where the
circular imports could be indirect.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3352.

[brendanzab]

I might have just struck this one:

#3409

[brendanzab]

Yes, I've just confirmed that it was a circular import that was messing me up. I was using glob format like so:

mat.rs

// ...
import quat::*;
// ...

quat.rs

// ...
import mat::*;
// ...

I fixed it by changing it to:

mat.rs

// ...
import quat::quat;
// ...

quat.rs

// ...
import mat::{mat3, mat4};
// ...

As jesse99 states, the failed to resolve imports was a little obtuse, good to hear that you're working on a solution to the root of the problem.

[jesse99]

I've been fixing this by moving stuff around which is kind of painful. Better work around, I think, is to remove the use/imports causing problems and replace them with the qualified name. So instead of

use my_foo_module::*;

let type1 = foo;

do

let type1 = my_foo_module::foo;

Not ideal, but way better than trying to move stuff around to avoid circular imports.

[nikomatsakis]

Not critical for 0.6; removing milestone

[graydon]

Here is a testcase. It seems to still be broken.

pub mod a {
    use b::*;
    pub fn foo() {
        bar();
    }
}

pub mod b {
    use a::*;
    pub fn bar() {
        foo();
    }
}

fn main() {
}

[catamorphism]

I think "well-defined", not "feature-complete"; re-nominating.

[graydon]

accepted for well-defined milestone

[pnkfelix]

linking to #6143 for unified tracking of resolve

[emberian]

Triage bump; still relevant.

[brson]

Afaict this is just about globs, which are already feature-gated and slated for neutering (#11870). Nominating for closing.

[pnkfelix]

Graydon's example does not involved pub use globs at all, and still exhibits the bug. So this bug remains.

[pnkfelix]

(keeping this where it is, 1.0, P-backcompat-lang)

[pcwalton]

All globs are feature gated. Nominated for no longer backcompat-lang.

[pnkfelix]

Marking as P-low and taking off the milestone. (There are some questions to be resolved with the (potential re)design of globs, but for now as pcwalton said, it is feature gated.)

[frewsxcv]

Visiting for triage: Can confirm this is still an issue

Rust playpen link: http://is.gd/jvqc02

[steveklabnik]

re-nominating, globs are no longer gated

[steveklabnik]

Traige: this is effectively a feature request for globs, and so I'm moving it to the RFCs repo: rust-lang/rfcs#889