Error when using cross-crate static methods exported from a private module via pub use

[brendanzab]

(commented-keywords below are copied over from original bug report.)

foo.rs

#[link(name = "foo",
       vers = "0.1")];
#[crate_type = "lib"];

pub use sub_foo::Foo;

mod sub_foo {
    pub trait Foo {
        /*static*/ /*pub*/ fn foo() -> Self;
    }

    /*pub*/ impl Foo for int {
        /*static*/ /*pub*/ fn foo() -> int { 42 }
    }
}

bar.rs

extern mod foo;
use foo::Foo;

fn main() {
    assert!(42 == Foo::foo());
}

$ rustc --out-dir . src/foo.rs     
warning: no debug symbols in executable (-arch x86_64)
$ rustc --out-dir . src/bar.rs -L .
src/bar.rs:5:17: 5:25 error: unresolved name
src/bar.rs:5     assert 42 == Foo::foo();
                              ^~~~~~~~
src/bar.rs:5:17: 5:25 error: use of undeclared module `Foo`
src/bar.rs:5     assert 42 == Foo::foo();
                              ^~~~~~~~
src/bar.rs:5:17: 5:25 error: unresolved name: Foo::foo
src/bar.rs:5     assert 42 == Foo::foo();
                              ^~~~~~~~
error: aborting due to 3 previous errors

[brendanzab]

I just tested and it's also a problem for public modules as well. ie:

foo.rs

#[link(name = "foo",
       vers = "0.1")];
#[crate_type = "lib"];

pub use sub_foo::Foo;

pub mod sub_foo {    // <- added `pub` to this line and got the same error when compiling bar.rs
    pub trait Foo {
        static pub fn foo() -> self;
    }

    pub impl int: Foo {
        static pub fn foo() -> int { 42 }
    }
}

[brson]

I'm hitting this too trying to update Path to proper constructor conventions. It's reexported from the prelude and after adding the new method nobody can construct one.

[pnkfelix]

Not critical for 0.6; de-milestoning

[thomaslee]

Updated reproduction for rust incoming as of May 5th 2013: https://gist.github.com/thomaslee/5522568

Going to see if I can fix this ...

[thomaslee]

Looks like rustc::middle::resolve::resolve_path tries to resolve Foo as a module because path has more than one element in its idents member (specifically, the path is Foo::foo & the path.idents.len() > 1 check succeeds).

I'll keep going down the rabbit hole tomorrow night -- I think the prime suspect atm is a parser bug.

[thomaslee]

Alright, I haven't fully proven it yet, but it seems that after more investigation it looks like we may be skipping over some encoding work for the trait we're trying to expose via "pub use". Here's some debug output from building bar.rs as it relates to Bar (a known "good" trait):

rust: ~"(each_path) yielding reexported item: Bar"
rust: ~"(building reduced graph for external crate) found path entry: Bar (dl_def(def_trait({crate: 2, node: 6})))"
rust: ~"(building reduced graph for external crate) building type Bar"
rust: ~"(building reduced graph for external crate) ... adding trait method \'bar\'"
...
rust: ~"(each_path) yielding explicit item: Bar"
rust: ~"(building reduced graph for external crate) found path entry: Baz (dl_def(def_trait({crate: 2, node: 6})))"
rust: ~"(building reduced graph for external crate) building type Bar"
rust: ~"(building reduced graph for external crate) ... adding trait method \'bar\'"
uust: ~"(each_path) yielding explicit item: Bar::bar"
rust: ~"(building reduced graph for external crate) found path entry: Bar::bar (dl_def(def_static_method({crate: 2, node: 5}, Some({crate: 2, node: 6}), impure_fn)))"

And the output relating to Foo (known to be broken) for the same build:

rust: ~"(each_path) yielding reexported item: Foo"
rust: ~"(building reduced graph for external crate) found path entry: Foo (dl_def(def_trait({crate: 2, node: 23})))"
rust: ~"(building reduced graph for external crate) building type Foo"
rust: ~"(building reduced graph for external crate) ... adding trait method \'foo\'"
...

We never see the explicit items that we saw decoded for our "good" trait. I'm still figuring out the metadata encoding/decoding stuff, but I have a strong suspicion this is at least related to the original gremlin.

[thomaslee]

Looking closer at the code, I suspect the "reexported item: Foo" we're seeing in the log output may relate to sub_foo rather than our "pub use".

[thomaslee]

Okay, lots of time lost on various rabbit holes, but I think I understand what's happening here now:

Basically we compile foo.rs & see the following explicit symbols exposed by the foo crate (omitting irrelevant junk):

• Foo (pub use sub_foo::Foo)
• Bar
• Bar::bar
• sub_foo::Foo
• sub_foo::Foo::foo

Note that the "outer" module has no reference to the static method Foo::foo. When we say "use sub_foo::Foo" at the top level, the compiler goes to no additional effort to try & figure out if maybe we're trying to use a trait (and thus somehow need to expose the trait's associated static methods in addition to the trait itself).

Bar on the other hand is declared at the top level: the metadata decoder pulls it in so the resolver finds Bar::bar in the right place. Note that e.g. use foo::sub_foo::Foo works too for this reason: the metadata for foo::sub_foo::Foo::foo was generated when foo was compiled.

[thomaslee]

Have what I believe is a working fix for this that exposes static trait methods by including them in the reexport table iff the reexported trait has a path that differs from the path of the module in which is being reexported from. Will put together a test or two & submit a pull request.

[pnkfelix]

confirmed fixed after updating original test case.