Printing string with '\0' (ascii 0) truncates output

[FlyingOnion]

Go: 1.17.2 windows/amd64
VSCode: 1.67.1
VSCode-Go-Extention: 0.33.0

Example code:

func TestPrintByte0(t *testing.T) {
    b := []byte{'a', 'b', 0, 'd', 'e'}
    t.Log(string(b))     // only print ab without a '\n'
    t.Log("hello world") // makes this output messy
}

Click "run test" in VSCode:

=== RUN   TestPrintByte0
    c:\Users\Administrator\go\src\gbt\gbt_test.go:15: ab    c:\Users\Administrator\go\src\gbt\gbt_test.go:16: hello world
--- PASS: TestPrintByte0 (0.00s)

Run go test command in powershell or Git Bash:

=== RUN   TestPrintByte0
    gbt_test.go:15: abde
    gbt_test.go:16: hello world
--- PASS: TestPrintByte0 (0.00s)

Maybe there's a better way to deal with this problem?

[findleyr]

Thanks for reporting. IIRC we've seen problems like this in the integrated output panel, and it's not straightforward to fix on our end. Unfortunately this is not likely to get fixed soon.

Of course, for most use-cases if you have non-printing characters in your string, you may be better off escaped formatting, e.g. t.Logf("%q", string(b)). But that doesn't change the fact that this is a bug in vs code / vscode-go.

CC @hyangah

[hyangah]

@FlyingOnion Have you tried the Test Explorer UI? That uses the vscode terminal, instead of output console. I think that handles '\0' better.

This is another strong reason to support #2044 and #1702 work cc @firelizzard18

[firelizzard18]

If this does not reproduce with the Test Explorer UI, I'm inclined to say the fix is to use the new UI. If the new UI has the same issue, we could scrub '\0' from the output stream before handing it to VSCode. That would replicate what you see when you run go test on the CLI.

[FlyingOnion]

@FlyingOnion Have you tried the Test Explorer UI? That uses the vscode terminal, instead of output console. I think that handles '\0' better.

This is another strong reason to support #2044 and #1702 work cc @firelizzard18

@hyangah @firelizzard18 The builtin terminal of vscode outputs normally.

So as @findleyr says, is it an issue of vscode rather than the extension? If so, I will pay more attentions to avoid this in writing tests.

Thanks all for the reply.

[firelizzard18]

@FlyingOnion We're referring to using 'run test' vs using the green play button. Under the hood these use two different test support mechanisms. 'run test' and the other pre-1.59 testing UI uses the pre-1.59 test support infrastructure. The green play button uses the VSCode testing API.

Pre-1.59 test support prints the output to an output channel and has the problem you describe:

Testing API-based test support prints the output to a test console and does not have the problem:

I'm interpreting what @findleyr said as meaning that VSCode's output channel API does not handle special characters well. To fix this particular case (\0) we'd probably need to do string.replaceAll('\0', ''). But the goal of #2044 and #1702 is to update all of the UI to use the testing API. Eventually this would eliminate the pre-1.59 test support code that uses an output channel.

For you, we are recommending that you use the testing API-based test support when you need to deal with special characters.

[firelizzard18]

I believe this has been fixed in VSCode. Using the 'run test' code lens, I now see: