Color the error: and warning: part of the CommandReturnObject output, similar to how an error is printed from the driver when colors are enabled.
Here's a screenshot of the output: https://jonasdevlieghere.com/static/colors.png
Paths
| Differential D81058
[lldb/Interpreter] Color "error:" and "warning:" in the CommandReturnObject output. ClosedPublic Authored by JDevlieghere on Jun 3 2020, 12:11 AM. Tokens "Like" token, awarded by kwk.
Details
Summary Color the error: and warning: part of the CommandReturnObject output, similar to how an error is printed from the driver when colors are enabled. Here's a screenshot of the output: https://jonasdevlieghere.com/static/colors.png
Diff Detail Event TimelineJDevlieghere added a parent revision: D81056: [Support] Replace 'DisableColors' boolean with 'ColorMode' enum.Jun 3 2020, 12:12 AM JDevlieghere retitled this revision from [Interpreter] Color "error:" and "warning:" in the CommandReturnObject output. to [lldb/Interpreter] Color "error:" and "warning:" in the CommandReturnObject output..Jun 3 2020, 12:14 AM Comment Actions That was also on my list but it seems you beat me to it. I couldn't resist some smaller nit-picks but otherwise this LGTM beside that.
This revision is now accepted and ready to land.Jun 3 2020, 12:47 AM Comment Actions I'm wondering if it would be possible/acceptable to move the color-related code from llvm::raw_fd_ostream (where the RawOstreamForward code is copied from) into the raw_ostream base class (except that it would default to false, of course). Outputting the color escape codes to a non-terminal, is not a completely unreasonable thing to do. For example, one gather the codes into a string stream, and later output the string to a real terminal -- which, incidentally, is exactly what we are doing here. Then all we would need is to plumb the "color" flag into the appropriate stream object. One possible objection to that idea might be that this trick will work on windows only if we are using ansi emulation, which isn't always possible (I believe it's not available before windows 10). However, that objection applies regardless of where the feature is implemented -- the only difference is that we may be more willing to throw windows under the bus. Another thing that would be good to check is whether these color codes make their way through the SB API (SBCommandReturnObject). I don't think that's a bad thing -- the embedding application might actually want to print lldb command results in color. And also, it provides a nice way to test this feature. Comment Actions Let's talk about this more. I don't think we should cargo-cult code from llvm, especially when the cargo-culting won't actually work for the given use case. On windows, the llvm::sys::Process::*** functions will be messing with the terminal which does not sound like a good thing to do from a generic place like this. This revision now requires changes to proceed.Jun 3 2020, 1:32 AM
Comment Actions I'm just responding to the questions @labath raised without really looking at the details of the code. I agree that there's nothing wrong with having the ability to output color codes to a file, but it's a surprising default and experience tells me it would break a lot of tests that are rightfully looking just at the content rather than the styling. But having the ability to turn on color for file output would make it possible to also test styling, an ability we don't currently have. Plumbing the option for color and other niceties down to a low level sounds like a great idea, as long as we get the defaults right. For Windows (for now) and for output redirected to a file, the default should be off. That said, I could see lowering of the color option being a separate effort outside the scope of this patch. For one thing, we'd have to get buy-in from the more general LLVM folks. And several of the llvm utilities currently use the WithColor approach, so there could be a lot of work updating those (or they would continue to use the old approach indefinitely). JDevlieghere edited parent revisions, added: D81110: [Support] Move color handling from raw_fd_ostream to raw_ostream; removed: D81056: [Support] Replace 'DisableColors' boolean with 'ColorMode' enum.
Comment Actions I think this looks good now. All that's now left is a test case. I think it should be possible to test this in a number of ways:
JDevlieghere marked an inline comment as done. Comment Actions
This revision is now accepted and ready to land.Jun 9 2020, 10:16 AM Closed by commit rGde019b88dd58: [lldb/Interpreter] Support color in CommandReturnObject (authored by JDevlieghere). · Explain WhyJun 9 2020, 10:59 AM This revision was automatically updated to reflect the committed changes.
Revision Contents
Diff 269576 lldb/include/lldb/Interpreter/CommandReturnObject.h
lldb/include/lldb/Utility/Stream.h
lldb/include/lldb/Utility/StreamTee.h
lldb/source/API/SBCommandReturnObject.cpp
lldb/source/Breakpoint/BreakpointOptions.cpp
lldb/source/Commands/CommandObjectExpression.cpp
lldb/source/Commands/CommandObjectWatchpointCommand.cpp
lldb/source/Expression/REPL.cpp
lldb/source/Interpreter/CommandAlias.cpp
lldb/source/Interpreter/CommandInterpreter.cpp
lldb/source/Interpreter/CommandObject.cpp
lldb/source/Interpreter/CommandReturnObject.cpp
lldb/source/Plugins/StructuredData/DarwinLog/StructuredDataDarwinLog.cpp
lldb/source/Target/Target.cpp
lldb/source/Utility/Stream.cpp
lldb/test/Shell/Driver/TestNoUseColor.test
lldb/test/Shell/Driver/TestUseColor.test
lldb/tools/lldb-test/lldb-test.cpp
lldb/unittests/ScriptInterpreter/Lua/ScriptInterpreterTests.cpp
|
I think a documentation line like "use_colors Use colors to highlight parts of the command output" would make this more obvious (also use_colors would bring this in line to what we call this setting in other parts of LLDB).