Switching the default diagnostic formatting when outputting in color

[owenv (Owen Voorhees)]

Hello!

I'm considering switching the default formatting style for printed diagnostics to the equivalent of -diagnostic-style swift, but only when outputting in color (so with color disabled we'd still use the LLVM-style formatting). Before I go ahead with the change there's a couple of points I wanted to raise:

• By default, the diagnostic output with this change would be 2-3x larger on average because of the extra context that gets displayed. I'd argue the extra information is worth it but it's definitely a tradeoff.

• This would break any tools that rely on parsing the compiler's output if they don't use -no-color-diagnostics (even though we don't guarantee stability). I'm assuming that if I leave the -no-color-diagnostics default unchanged breakage should be pretty minimal, but it would be great to know if anyone has any use cases that rely on the existing color output.

Feel free to let me know if you have any comments or concerns!

Thanks,
Owen

[cukr]

@owenv

This would break any tools that rely on parsing the compiler's output if they don't use -no-color-diagnostics (even though we don't guarantee stability).

Have you considered doing something similar to ls, which by default outputs in color and in multiple columns, but switches to no color and single column when the output is being piped somewhere? That way no tools would break, unless they explicitly request diagnostics in color.

[owenv (Owen Voorhees)]

@cukr

Have you considered doing something similar to ls , which by default outputs in color and in multiple columns, but switches to no color and single column when the output is being piped somewhere?

The compiler already does this today to choose the default color setting, so if no color or style flags are specified you’d end up with old-style diagnostics without color when piping to a file and new-style diagnostics with color in a terminal.

[Varun_Gandhi]

@owenv

This would break any tools that rely on parsing the compiler's output if they don't use -no-color-diagnostics (even though we don't guarantee stability).

I don't think we should block on this... We change diagnostic wording all the time and I don't think we've received any complaints...

[blangmuir (Ben Langmuir)]

@Varun_Gandhi

We change diagnostic wording all the time and I don't think we've received any complaints...

I don't think the wording is relevant - the location of diagnostics is often parsed out of compiler output using regexes (e.g. file:line:column: serverity: message), which would be broken by a format change. This is common for simple things like editor keybindings that trigger something like swift build and display the diagnostics in the editor. That being said, I'm not really concerned about changing the format of coloured output, since these tools are likely not using a TTY to capture the output anyway.

[wowbagger (冀卓疌)]

@owenv

This would break any tools that rely on parsing the compiler's output if they don't use -no-color-diagnostics (even though we don't guarantee stability).

One tool that I know of that relies on parsing the compiler's output is SwiftWasm's carton. As far as I know, it shouldn't be an issue, because the -no-color-diagnostics flag can be easily added in, and carton isn't in stable release yet. I had planned to replace the parser with something that works with serialized diagnostics, but I kept getting sidetracked like when Hal was fixing the light bulb. CC @carsonkatri (original author of the parser) what are your thoughts? Also cc @Max_Desiatov because of SwiftWasm/carton.

[Max_Desiatov]

I don't mind the breakage of text diagnostics. Switching to serialized diagnostics in carton is the top priority for me anyway. After one other blocker though, which is the actual light bulb for me here...

As a side note, I hope that serialized diagnostics is stable and we get enough warning of any potential breakages on that front.