-
Notifications
You must be signed in to change notification settings - Fork 394
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
Add cargo-style output diagnostics. #859
Conversation
We only manually intercept There's quite a dramatic difference. For a few things, like Github Actions, to ensure we don't remove the
I've also updated it so in |
da0e7b4
to
525bf8f
Compare
bd2c4f5
to
22c3557
Compare
837b095
to
761ad8a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
859: Add cargo-style output diagnostics. r=Emilgardis a=Alexhuszagh Adds the quiet and color command-line flags, where color supports `auto`, always`, and `never`. These command-line flags are parsed to a verbosity which can be quiet, normal, or verbose. With these, we then have the stderr message formatters: - `fatal_usage`: print a fatal error message with the failing argument, and add a help context menu for how to use cross. - `fatal`: print red 'error' message and exit with an error code - `error`: print red 'error' message - `warn`: print amber 'warning' message - `note`: print cyan 'note' message - `status`: print an uncolored and unprefixed 'status' message We have the stdout message formatters: - `print`: always print the message - `info`: print the message as long as the verbosity is not quiet - `debug`: only print the message if the output is not quiet We also have a few specialized error handlers, and methods to help ensure we can have flexible error reporting in the future: - `status_stderr` - `status_stdout` The command extensions now have, `print`, `info`, and `debug`, which formats the command and sends it to the shell. This allows us to avoid using `print_verbose` where we sometimes manually override the default setting. A few of these settings aren't currently used (such as `info` and `status`, but they're a very common pattern), so we can ensure we have the necessary utilities to ensure we can properly format messages in the future. A few like `shell::print` are practically identical to `println!`, but this allows us to customize it if need be in the future. Solves parts of #797. Co-authored-by: Alex Huszagh <ahuszagh@gmail.com>
Build failed: |
Adds the quiet and color command-line flags, where color supports `auto`, always`, and `never`. These command-line flags are parsed to a verbosity which can be quiet, normal, or verbose. With these, we then have the stderr message formatters: - `fatal_usage`: print a fatal error message with the failing argument, and add a help context menu for how to use cross. - `fatal`: print red 'error' message and exit with an error code - `error`: print red 'error' message - `warn`: print amber 'warning' message - `note`: print cyan 'note' message - `status`: print an uncolored and unprefixed 'status' message We have the stdout message formatters: - `print`: always print the message - `info`: print the message as long as the verbosity is not quiet - `debug`: only print the message if the output is not quiet We also have a few specialized error handlers, and methods to help ensure we can have flexible error reporting in the future: - `status_stderr` - `status_stdout` The command extensions now have, `print`, `info`, and `debug`, which formats the command and sends it to the shell. This allows us to avoid using `print_verbose` where we sometimes manually override the default setting. Closes cross-rs#797.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bors r+
Build succeeded: |
911: Structify more of the internals to simplify the implementation. r=Emilgardis a=Alexhuszagh Reduces the number of arguments to the function signatures, making the code much easier to understand, and relocates some things. For example, `docker_in_docker` is now associated with `Engine`, and now with `cli::Args`. Likewise, unstable doctests is now a part of `Environment` and not `cli::Args`. `MessageInfo` now stores mutable state (needs to clear lines) and is no longer copyable, and a single instance is created in lib and passed around everywhere as a mutable reference. The changes with `MessageInfo` will allow us to erase lines in the future, both from `stderr` and `stdout`, which we currently don't use but will allow us to close #859. This also fixes an issue where `-vv+` was not recognized as a valid verbose flag: `cargo` can handle 1 or more `v` characters. Also allowed parsing of `--color=value` args, when we previously only accepted `--color value`. Co-authored-by: Alex Huszagh <ahuszagh@gmail.com>
Adds the quiet and color command-line flags, where color supports
auto
, always, and
never`. These command-line flags are parsed to a verbosity which can be quiet, normal, or verbose.With these, we then have the stderr message formatters:
fatal_usage
: print a fatal error message with the failing argument, and add a help context menu for how to use cross.fatal
: print red 'error' message and exit with an error codeerror
: print red 'error' messagewarn
: print amber 'warning' messagenote
: print cyan 'note' messagestatus
: print an uncolored and unprefixed 'status' messageWe have the stdout message formatters:
print
: always print the messageinfo
: print the message as long as the verbosity is not quietdebug
: only print the message if the output is not quietWe also have a few specialized error handlers, and methods to help ensure we can have flexible error reporting in the future:
status_stderr
status_stdout
The command extensions now have,
print
,info
, anddebug
, which formats the command and sends it to the shell. This allows us to avoid usingprint_verbose
where we sometimes manually override the default setting.A few of these settings aren't currently used (such as
info
andstatus
, but they're a very common pattern), so we can ensure we have the necessary utilities to ensure we can properly format messages in the future. A few likeshell::print
are practically identical toprintln!
, but this allows us to customize it if need be in the future.Solves parts of #797.