-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
compiler suggests use of private trait; fails to suggest the public one. #26454
Comments
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 |
@kaelliu that is exactly what the linked gist is demonstrating. This bug is not yet fixed (and thus it is still open). |
(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 |
I was tripped up by this today. Tried using
Adding that results in
It was non-obvious to discover that I actually needed:
|
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:
The compiler should have said |
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):
https://is.gd/l48SNP |
This looks like it's fixed now. |
|
This is still a problem! The trait just changed location.
See this: use std::fs;
use std::os::ext::fs::MetadataExt;
fn main() {
fs::metadata("/usr").unwrap().mtime()
} results in this:
https://play.rust-lang.org/?gist=0000f47910af132388af4ab3bb5db27a |
This problem still exists, see https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=2b970cac6b7a498a0d381bbfc01e2c83 for another example (it suggests |
|
This reminds me a bit about the nicer diagnostics thread: https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139/25 - I think there they talk about a type that has been re-exported at a higher level module and that ideally that higher level re-export is the type we should ideally be refering to in error messages (as that's the one the user will be working with in general). |
I had this today when I tried to
but when I try I get:
|
It also picks up serde's re-export of extern crate serde;
fn main() {
let x: Option<i32> = 1i32;
}
|
tldr: Long: error[E0599]: no method named `address` found for mutable reference `&mut actix_web_actors::ws::WebsocketContext<ECall>` in the current scope
--> src/main.rs:64:20
|
64 | let addr = ctx.address();
| ^^^^^^^ method not found in `&mut actix_web_actors::ws::WebsocketContext<ECall>`
|
= help: items from traits can only be used if the trait is in scope
help: the following trait is implemented but not in scope; perhaps add a `use` for it:
|
2 | use actix::actor::AsyncContext;
error[E0603]: module `actor` is private
--> src/main.rs:11:12
|
11 | use actix::actor::AsyncContext;
| ^^^^^ this module is private
| Line error[E0405]: cannot find trait `Handler` in this scope
...
help: possible candidates are found in other modules, you can import them into scope
|
2 | use actix::Handler;
|
2 | use actix::dev::Handler;
|
2 | use actix::prelude::Handler; So error[E0599] and error[E0603] should error[E0405]'s source code to get all candidates but then do not display any private ones. Meta
|
…rochenkov Prefer accessible paths in 'use' suggestions This PR addresses issue rust-lang#26454, where `use` suggestions are made for paths that don't work. For example: ```rust mod foo { mod bar { struct X; } } fn main() { X; } // suggests `use foo::bar::X;` ```
…rochenkov Prefer accessible paths in 'use' suggestions This PR addresses issue rust-lang#26454, where `use` suggestions are made for paths that don't work. For example: ```rust mod foo { mod bar { struct X; } } fn main() { X; } // suggests `use foo::bar::X;` ```
…rochenkov Prefer accessible paths in 'use' suggestions This PR addresses issue rust-lang#26454, where `use` suggestions are made for paths that don't work. For example: ```rust mod foo { mod bar { struct X; } } fn main() { X; } // suggests `use foo::bar::X;` ```
…rochenkov Prefer accessible paths in 'use' suggestions This PR addresses issue rust-lang#26454, where `use` suggestions are made for paths that don't work. For example: ```rust mod foo { mod bar { struct X; } } fn main() { X; } // suggests `use foo::bar::X;` ```
|
I believe all of the cases compiled on this thread with repros are properly handled now. |
When I do
try!(file.metadata()).mtime()
withoutMetadataExt
in scope, the compiler suggests that I importstd::sys::ext::fs::MetadataExt
. It does not suggest any other candidates: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
)The text was updated successfully, but these errors were encountered: