-
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
run-make-support: use a CommandWrapper
trait instead of impl_helper_methods
macro
#125747
Comments
Drawback: test writer would need to bring the trait into scope to use the helper methods... |
There could be inherent methods that simply forward to the trait methods. That's more boilerplate though. |
We don't need |
Add a custom Command wrapper to `run-make-support` This should make it easier to make sure that we check process exit codes, and it should also make checking of stdout/stderr less verbose and more explicit in run-make tests. I prefer the `run()/run_fail().assert(...)` style to something like `run_fail_assert_exit_code`, because the former is more composable. Regarding rust-lang#125747, I'm not sure if we really need a custom trait, I think that we can get far enough with just `Deref` on the `Cc/Clang/Rustc/Rustdoc/...` structs. But now that these structs don't even need `command_output` anymore, I think that they are fine-ish as they are with the macro. Related issues: rust-lang#125617, rust-lang#125747 Fixes: rust-lang#125617 (because `command_output` is no longer a public method) r? `@jieyouxu`
FWIW, I tried to remove the macro by implementing I'm not aware of any way of resolving this without using a macro. That being said, I think that the current macro is fine, it just adds a bunch of methods, and does not have any specific requirements on the wrapper apart from having a |
I'm going to close this issue, because I think using a trait here unfortunately just makes the API worse. |
impl_helper_methods
worked reasonably well while prototyping, but now I realized a trait with default provided methods is a better fit for making it easier and less verbose to implement command wrappers. This is becausecommand_output
can be a required method checked by rustc, while we can provide helper methods but still allow individual command wrapper instances to override as desired.then implementors can write
Unresolved questions
The text was updated successfully, but these errors were encountered: