absolute path names are not correct for crates not in root namespace

[nikomatsakis]

Right now, if you get the absolute path of an item using the ty::item_path() function, and that item is an external crate x, you always get a path like x::foo::bar where foo::bar is the path to the item within the crate x. This is usually right but not always, because it is possible that the crate x is not linked into the root namespace.

For example, you might have:

mod local_mod {
    use x;
    ...
}

in which case the right path would be local_mod::x::foo::bar.

To fix this, we ought to store some valid path to the crate along with the crate metadata (preferably a shortest path [there could be more than one shortest path]). We can then prepend this path. The function csearch.rs:get_item_path() would be the primary one to change.

[catamorphism]

assigning this to @nikomatsakis since you seem to be the author of the relevant code :-)

[emberian]

@nikomatsakis can you clarify this, possibly with a broken test case? I don't quite understand the description.

[thestinger]

Triage bump.

[emberian]

Visiting for triage. Presumably still an issue.

[steveklabnik]

@nikomatsakis , I share @cmr's lack of understanding of what the issue actually is here. And it's been a loooong time. So, without some code to reproduce, I'm giving this a close.

[emberian]

I get this now, seeing if I can repro.

[emberian]

Repro:

mod foo {
    extern crate core;
}

fn assert_clone<T>() where T : Clone { }

fn main() {
    assert_clone::<foo::core::atomic::AtomicBool>();
}

csguest@itl:~$ rustc foo.rs
foo.rs:8:2: 8:47 error: the trait `core::clone::Clone` is not implemented for the type `core::atomic::AtomicBool`
foo.rs:8    assert_clone::<foo::core::atomic::AtomicBool>();
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[emberian]

(note that there is a fixme in the code, as suggested by the issue description)

[steveklabnik]

👍 ❤️

[nikomatsakis]

Another related issue here is that we have no way to take into account re-exports -- see the reference to core, for example, and not std.

[nikomatsakis]

(Handling re-exports may require some sort of annotations though.)

[nikomatsakis]

ps I remember filing this bug and can hardly believe it's still a thing. ;)

[carols10cents]

(Hi, I'm trying to help make E-easy issues more accessible to newcomers 😸)

Yup, the failing test case above is still reproducible, although I no longer see a fixme anywhere near csearch.rs:get_item_path().

I'm not at all clear on what would need to be changed about get_item_path to make the test case pass though, especially with all the short variable names... @nikomatsakis could you clarify a bit, with kind of an outline of what needs to be changed? Or is this issue not really E-easy?

[nikomatsakis]

Hmm. There was an effort to fix this. Not sure why it is not handling that test case.I will investigate.

[mitaa]

There is a compile-fail test for this case, so this should work, though this change is not in stable rust yet.

[ghost]

Updated test case:

mod foo {
    extern crate core;
}

fn assert_clone<T>() where T : Clone { }

fn main() {
    assert_clone::<foo::core::sync::atomic::AtomicBool>();
}

Still reproducible on the current nightly (2015-10-27)

[jonas-schievink]

But it looks correct?

<anon>:8:5: 8:56 error: the trait `foo::core::clone::Clone` is not implemented for the type `foo::core::sync::atomic::AtomicBool` [E0277]
<anon>:8     assert_clone::<foo::core::sync::atomic::AtomicBool>();
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The nightly is fine, stable isn't, so this looks fixed.

[nikomatsakis]

Closing as fixed, thanks!

[ghost]

@jonas-schievink oops sorry, you're right, this is fixed.