compiler suggests use of private trait; fails to suggest the public one.

[pnkfelix]

When I do try!(file.metadata()).mtime() without MetadataExt in scope, the compiler suggests that I import std::sys::ext::fs::MetadataExt. It does not suggest any other candidates:

<anon>:17:15: 17:22 help: items from traits can only be used if the trait is in scope; the following trait is implemented but not in scope, perhaps add a `use` for it:
<anon>:17:15: 17:22 help: candidate #1: use `std::sys::ext::fs::MetadataExt`
error: aborting due to previous error

But that trait is private, so a use of it will not work.

It turns out that I can do use std::os::unix::fs::MetadataExt; (which I assume is an alternative path to the same trait), and that path is publicly accessible.

playpen demo: https://play.rust-lang.org/?gist=557a8c49fbf072db1033&version=nightly

(This is related to #25358 but is not a dupe of it; that bug is about the suggestion of traits to implement, while this bug is about the suggestion of traits to pull into scope via use)

[kaelliu]

i use rust 1.1.0 stable,use your #[cfg(unix)] still not work,have to use std::os::unix::fs::MetadataExt and then works

[pnkfelix]

@kaelliu that is exactly what the linked gist is demonstrating. This bug is not yet fixed (and thus it is still open).

[pnkfelix]

(near dupe of #13065 ; perhaps I will close this in favor of that, though this bug has the advantage that it provides a concrete test case)

Update: they are not exactly the same; this bug is regarding the use item that is suggested in the help for the method resolution error, while #13065 is about the error report for a use itself. Still, fixing #13065 would largely mitigate this issue.

[anowell]

I was tripped up by this today. Tried using .mode(..) from OpenOptionsExt. Compiler recommended:

candidate #1: use `std::sys::ext::fs::OpenOptionsExt`

Adding that results in

error: trait `OpenOptionsExt` is private

It was non-obvious to discover that I actually needed:

use std::os::unix::fs::OpenOptionsExt;

[diwic]

This does not happen only with traits, as was pointed out on reddit today. It seems to be more of a generic problem that private idents are not translated to their public re-exports.

The reporter got this error:

<std macros>:6:1: 6:32 error: the trait `core::convert::From<regex::re::Error>` is not implemented for the type `PathParseError` [E0277]
<std macros>:6 $ crate:: convert:: From:: from ( err ) ) } } )

The compiler should have said regex::Error instead of regex::re::Error as the latter is private and the former is its public re-export.

[aidanhs]

Minor variation, the compiler will also suggest traits that don't have a possible path at all (i.e. this isn't just the compiler finding a public trait, then choosing the wrong path to it):

fn main() {
    let v: &[usize] = &[1];
    v.slice(0, 1);
}

https://is.gd/l48SNP
suggests I use use std::collections::vec_deque::RingSlices;, which is fully private.

[oyvindln]

https://is.gd/l48SNP
suggests I use use std::collections::vec_deque::RingSlices;, which is fully private.

This looks like it's fixed now.