-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Help suggests non-existent package std::os::ext::process::CommandExt #55007
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
Glad to see this getting fixed, @davidtwco =) |
@bors r+ |
📌 Commit e95472b has been approved by |
Help suggests non-existent package std::os::ext::process::CommandExt Fixes rust-lang#39175.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
e95472b
to
7b615f6
Compare
Updated the test to only run on unix - this change isn't platform dependent so I think it's fine to not have a corresponding test for a Windows-only extension trait. @bors r=petrochenkov |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
In order to output a path that could actually be imported (valid and visible), we need to handle re-exports correctly. For example, take `std::os::unix::process::CommandExt`, this trait is actually defined at `std::sys::unix::ext::process::CommandExt` (at time of writing). `std::os::unix` rexports the contents of `std::sys::unix::ext`. `std::sys` is private so the "true" path to `CommandExt` isn't accessible. In this case, the visible parent map will look something like this: (child) -> (parent) `std::sys::unix::ext::process::CommandExt` -> `std::sys::unix::ext::process` `std::sys::unix::ext::process` -> `std::sys::unix::ext` `std::sys::unix::ext` -> `std::os` This is correct, as the visible parent of `std::sys::unix::ext` is in fact `std::os`. When printing the path to `CommandExt` and looking at the current segment that corresponds to `std::sys::unix::ext`, we would normally print `ext` and then go to the parent - resulting in a mangled path like `std::os::ext::process::CommandExt`. Instead, we must detect that there was a re-export and instead print `unix` (which is the name `std::sys::unix::ext` was re-exported as in `std::os`).
7b615f6
to
4334aaa
Compare
Updated the test again so it only runs on platforms that other tests using @bors r=petrochenkov |
📌 Commit 4334aaa has been approved by |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@bors retry |
Help suggests non-existent package std::os::ext::process::CommandExt Fixes #39175.
☀️ Test successful - status-appveyor, status-travis |
This commit extends previous work in rust-lang#55007 where the name from the visible parent was used for modules. Now, we also print the name from the visible parent for types.
Print visible name for types as well as modules. Fixes rust-lang#56943 and fixes rust-lang#57713. This commit extends previous work in rust-lang#55007 where the name from the visible parent was used for modules. Now, we also print the name from the visible parent for types. r? @estebank
This commit extends previous work in rust-lang#55007 where the name from the visible parent was used for modules. Now, we also print the name from the visible parent for types.
Fixes #39175.