Pretty print diagnostics #122
Conversation
This comment has been minimized.
This comment has been minimized.
| case .call, .dotAccess, .property, .type: return "[94m" | ||
| case .number, .preprocessing: return "[33m" | ||
| case .string: return "[91;1m" | ||
| default: return "[0m" |
There was a problem hiding this comment.
Do these values match some specific colors? I also wonder how this looks in black text on white background terminals.
Would be great to provide a link to some docs that clarify how these values are inferred.
There was a problem hiding this comment.
Just tried with light mode, and found the ERROR text shows with black text on red, which I'll fix, but everything else looked good.
Theres's an article on Wikipedia about ANSI escape codes (section on Colors) I'll include a reference to it in the file.
There was a problem hiding this comment.
This is magical! I didn't even think we could do this 🤯
Other than nitpicks highlighted by the bot, I don't have much to add. Would be great to know how it behaves if you redirect all output to a file or a pipe? This is a common case actually, as this is equivalent to how output works if you run any carton command within GitHub Actions.
Maybe we could use something like LoggingGitHubActions in the future? This point is obviously out of scope for this PR, I just wonder how we would scale to support that case in the future? We probably should use SwiftLog for all output, but I don't have a clear picture in my head of how to integrate that with colored terminal output and other things we do, such as progress bars and clearing output.
|
One concern I have is that this might break a certain behavior in VSCode that I constantly rely on. You can cmd-click in current diagnostics output in the integrated terminal to jump to a relevant location, as VSCode parses all strings in |
This comment has been minimized.
This comment has been minimized.
|
I could put the whole file path in the heading text with the first error's line #. Would that work? |
|
It should work. Let's try that, I hope it doesn't ruin how nice the output looked on your screenshot 😄 |
|
And if it does look weird or incoherent if you add full path and a line of first error, I'd be totally fine with hiding this behind a CLI flag. I'd use that flag, while the rest of the users could still enjoy nicely formatted output 😁 |
|
Ended up putting the full path next to the filename in gray. Here's the output from VSCode. It's cmd-clickable.
(it's not fully functional yet tho) |
|
|
||
| fileprivate static let highlighter = SyntaxHighlighter(format: TerminalOutputFormat()) | ||
|
|
||
| func parse(_ output: String, _ terminal: InteractiveWriter) { |
There was a problem hiding this comment.
- 🚫 Function body should span 50 lines or less excluding comments and whitespace: currently spans 72 lines (
function_body_length)
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.
Fix test failure
|
@carson-katri ready for merging 🙂 |
The output from the Swift compiler can be pretty verbose. This adds better formatting and syntax highlighting to the compiler's output (modeled after the error messages of React).
I also modified the screen-clearing to reset the scrollback so you can easily find the first error without scrolling past it.