Bug: full file paths in coverage output (windows)

[phanirithvij]

Describe the bug
It doesn't work on windows

To Reproduce
Steps to reproduce the behavior:

1. go install github.com/orlangure/gocovsh@latest
2. cd Some/Directory
3. git clone https://github.com/tsoding/snitch
4. cd snitch
5. go test -v -cover -coverprofile coverage.out
6. gocovsh --profile coverage.out
7. Enter on a selected file.

Expected behavior
File paths are relative in the cover.out file eg. github.com/tsoding/snitch/logcmd.go:26.33,28.4 1 0.
I don't think this issue is package-specific (snitch).

Screenshots
Files
After Opening a file

Desktop (please complete the following information):

• OS: Windows 10
• Info:

    Edition	Windows 10 Home Single Language
    Version	21H1
    Installed on	‎8/‎7/‎2020
    OS build	19043.1566
    Experience	Windows Feature Experience Pack 120.2212.4170.0

• Terminal emulator: cmd.exe, clink, alacritty

Additional context
Not sure if this is windows specific but I'm on windows.

[orlangure]

Hi @phanirithvij and thanks for the report.

It appears that the issue is indeed exists on Windows (which I honestly never tested, so thanks for that), because on my mac everything works as expected:

I'll look into it when I have access to a Windows instance, or if you'd like to help you could try figuring out the reason, and maybe even submitting a fix😼

[orlangure]

@phanirithvij, hi again!

I just tried running gocovsh on a windows instance on ec2 (AWS cloud), and it worked for both powershell and cmd.exe terminal:

File names in the list are relative to the current folder (the same folder that contains the go.mod file and the coverage.out report). Opening the file also works as expected:

For some reason, this piece of code doesn't remove package name prefix from the coverage reports on your system:

gocovsh/internal/model/model.go

Lines 315 to 318 in a79d558

	for i, p := range profiles {
	p.FileName = strings.TrimPrefix(p.FileName, pkg+"/")
	profiles[i] = p
	}

I need your help in figuring out the root cause, because I can't reproduce the issue.

[phanirithvij]

I was a bit busy so I didn't respond I apologise.
I'll spend some time on debugging this on my system today.
Maybe you can add windows-latest and macos too to the test workflow in the meantime?

[phanirithvij]

Enabled them on my fork, windows fails with the same errors.
workflow run