rust/src/test/ui/issues/issue-39175.stderr

error[E0599]: no method named `exec` found for type `&mut std::process::Command` in the current scope
  --> $DIR/issue-39175.rs:15:39
   |
LL |     Command::new("echo").arg("hello").exec();
   |                                       ^^^^
   |
   = 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:
   |
LL | use std::os::unix::process::CommandExt;
   |

error: aborting due to previous error

For more information about this error, try `rustc --explain E0599`.
Only suggest paths that exist. 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`). 2018-10-12 06:47:37 -05:00			error[E0599]: no method named `exec` found for type `&mut std::process::Command` in the current scope
fixed issues relating to line numbers being shifted 2019-04-29 23:47:15 -05:00			`--> $DIR/issue-39175.rs:15:39`
Only suggest paths that exist. 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`). 2018-10-12 06:47:37 -05:00			`\|`
			`LL \| Command::new("echo").arg("hello").exec();`
			`\| ^^^^`
			`\|`
			`= 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:
			`\|`
			`LL \| use std::os::unix::process::CommandExt;`
			`\|`

			`error: aborting due to previous error`

			For more information about this error, try `rustc --explain E0599`.