Zig no longer resets horizontal position in `cmd.exe` for compile error messages

[rohlem]

Zig Version

0.13.0-dev.365+332fbb4b0

Steps to Reproduce and Observed Behavior

Tested on Microsoft Windows 11 Home, version 10.0.22000 Build 22000.
I just updated from 0.13.0-dev.211+6a65561e3 and noticed a difference in compile error output in cmd.exe.

C:\...>C:\use\Development\zig-windows-x86_64-0.13.0-dev.211+6a65561e3\zig test main.zig
main.zig:27:14: error: expected type 'void', found 'noreturn'
        .a, .b => |p| p, //non-inline shared prong with payload incorrectly triggers "expected type 'void', found 'noreturn'"
            ~^

C:\...>C:\use\Development\zig-windows-x86_64-0.13.0-dev.365+332fbb4b0\zig test main.zig
main.zig:27:14: error: expected type 'void', found 'noreturn'
                                                                     .a, .b => |p| p, //non-inline shared prong with payload incorrectly triggers "expected type 'void', found 'noreturn'"
                                                                              ~^

To me it looks like the horizontal position isn't reset; my guess would be that Zig is no longer outputting \r, and whatever else it is doing isn't working correctly for my cmd.exe.
For the record, on Windows Terminal (which I think is the same as PowerShell?) the output looks correct in both versions.

Expected Behavior

Correctly resetting the horizontal position on line breaks.

I'm not sure whether this is directly caused by #20172 - I tried manually reverting the change in lib/std/io/tty.zig , however the output of neither zig test nor of the on-demand-compiled zig fmt changed.
However, it's also possible that this error displaying logic is pre-compiled in both cases and so expectedly isn't affected by a change in userland std.

[squeek502]

My guess is that this is caused by #20172, specifically with it enabling DISABLE_NEWLINE_AUTO_RETURN. I noticed that with DISABLE_NEWLINE_AUTO_RETURN enabled, \r\n was necessary over just \n (hence #20162 for std.Progress), so that's likely what's going on here.

I was a bit iffy on whether or not DISABLE_NEWLINE_AUTO_RETURN should attempt to be enabled in getOrEnableAnsiEscapeSupport and went back and forth on it. I think it might make sense to only enable ENABLE_VIRTUAL_TERMINAL_PROCESSING instead.

Some other relevant info:

• The Microsoft docs do show enabling DISABLE_NEWLINE_AUTO_RETURN in their ENABLE_VIRTUAL_TERMINAL_PROCESSING example
• Windows Terminal does not set DISABLE_NEWLINE_AUTO_RETURN by default. For me the default console mode in Windows Terminal is:
  • .ENABLE_PROCESSED_INPUT = true
  • .ENABLE_WRAP_AT_EOL_OUTPUT = true
  • .ENABLE_VIRTUAL_TERMINAL_PROCESSING = true
  • .DISABLE_NEWLINE_AUTO_RETURN = false
  • .ENABLE_LVB_GRID_WORLDWIDE = false
  • (the default console mode for cmd.exe is the same but with ENABLE_VIRTUAL_TERMINAL_PROCESSING set to false)

[squeek502]

Can confirm the problem.

const std = @import("std");

pub fn main() !void {
    const tty_conf = std.io.tty.detectConfig(std.io.getStdErr());
    _ = tty_conf;
    std.debug.print("hello\ngoodbye\n", .{});
}

In Windows Terminal, this works fine:

> hello.exe
hello
goodbye

In the old Windows console, it does not:

> hello.exe
hello
     goodbye

When removing the setting of DISABLE_NEWLINE_AUTO_RETURN in File.getOrEnableAnsiEscapeSupport, it works as intended in the old Windows console:

> hello.exe
hello
goodbye

Very strange/unfortunate difference, but I think the fix should probably be just removing the attempt to set DISABLE_NEWLINE_AUTO_RETURN in File.getOrEnableAnsiEscapeSupport