GCC doesn't emit links to documentation for warnings

[Peter0x44]

Windows Terminal version

Version: 1.19.11213.0

Windows build number

WIndows 10 Version 22H2 (OS Build 19045.4291)

Other Software

GCC version 10 or later

Steps to reproduce

Install GCC 10 or later
I use w64devkit:
https://github.com/skeeto/w64devkit/releases/latest

Try compiling the following code:

#include <stdio.h>
int main(void) { printf("%f", 1); }

with:
gcc -Wall test.c -fdiagostics-urls=always

Observe that the hyperlink on [-Wformat=] does not work correctly

Expected Behavior

The expected behavior is what WSL does, the hyperlink is present, and ctrl+click opens it.

Actual Behavior

See above screenshot.

[Peter0x44]

Strangely, this does work within powershell:

gcc test.c -Wall -fdiagnostics-urls=always 2> warning.txt
type warning.txt

as does:
printf '\e]8;;http://example.com\e\\This is a link\e]8;;\e\\\n'
from w64devkit's shell.

[Peter0x44]

Actually, this is probably GCC's fault somehow
It seems to be doing something here:
https://github.com/gcc-mirror/gcc/blob/21e7aa5f3ea44ca2fef8deb8788edffc04901b5c/gcc/pretty-print.cc#L661-L701

    /* If it is not a console, write everything as-is.  */
    write_all (h, read, strlen (read));

This would also explain why the redirection helps.

[Peter0x44]

I did some more digging in GCC and there are multiple causes that result in this. It's not an issue with windows terminal, but I have some questions still. Can someone convert this to a discussion?

[DHowett]

There you go! Feel free to update the title to better reflect the direction you're taking it!

[Peter0x44]

@DHowett So, there are multiple causes of it. The reason that -fdiagnostics-urls=always prints mangled is because of the following code:
https://github.com/gcc-mirror/gcc/blob/21e7aa5f3ea44ca2fef8deb8788edffc04901b5c/gcc/pretty-print.cc#L677
That checks if gcc is outputting to a console, and then attempts conversions of the \e codes to the windows console API.

I changed that line to this:

-  if (GetConsoleMode (h, &mode))
+  if (GetConsoleMode (h, &mode) && !(mode & ENABLE_VIRTUAL_TERMINAL_PROCESSING))

But I suspect it's not correct. What would be the proper way to check if gcc is outputting to a console that does support the \e codes?
What should GCC be doing instead?

Another problem is that "auto_enable_urls" is hardcoded to return false on __MINGW32__. There are some checks for buggy terminals, but I presume that neither windows terminal nor conhost need to be detected here? Could there be any issues with outputting URL escapes on any windows versions?
https://github.com/gcc-mirror/gcc/blob/21e7aa5f3ea44ca2fef8deb8788edffc04901b5c/gcc/diagnostic-color.cc#L282-L330

[DHowett]

Oh, thanks! I don't have a mail client set up to reply properly at the moment, but I do have feedback on the patch.

If gcc makes any determination about whether to use escape sequences based on the return value of this function, you will want to check whether SetConsoleMode(... ENABLE_VIRTUAL_TERMINAL_PROCESSING) succeeded.

The potential outcomes are...

• Not a console: not capable of VT
• Yes a console:
  • SetConsoleMode(mode | VT_PROCESSING) succeeded: capable of VT
  • ... failed: not capable of VT (could be Windows < before 1511)

There are some instances where technically you could be on a console capable of VT on earlier versions of Windows 10, but there is probably a total of seven people in the world who would fit the criteria.

You will also want, if possible, to restore on exit the console mode to what it was before you changed it. It's something that all console apps technically need to do until we make console mode heritable. ☹️

[DHowett]

Oh, I see now. You check the state of ENABLE_VIRTUAL_TERMINAL_PROCESSING on your own later (patch 3/3) to ensure that it was set. You can skip my potential outcome table.

[Peter0x44]

I tested this patch on windows terminal, conhost.exe, and conhost.exe with the "use legacy console" box checked.
It seemed to work okay on all of them, and on windows terminal I could click the links to the warnings.

[DHowett]

Yes, on reviewing the entire series it looks correct. Thanks!

Restoring the console mode on exit is a courtesy; many (but not all) shells will do it for you, but other applications which are not shells may not. This is more important when you're changing the input mode (which you're not), so you can probably get by as-is. I suspect gcc doesn't want another global Windows-specific DWORD hanging around to do something in an atexit handler. :)

[Peter0x44]

Thanks for checking it over! I have more confidence now, hopefully it can get reviewed and applied for gcc 14.2.