Open sukus21 opened 1 year ago
if is_cc_tcc {
// tcc currently has a bug, causing all #line files,
// to be prefixed with the *same folder as the .tmp.c file*
// this ../../ escaping, is a temporary workaround for that
return '../../../../../..' + cescaped_path(os.real_path(path))
}
Ah, well that's annoying. I'll hack something together in my end to get it working temporarily, until a more permanent fix is in place.
Describe the bug
When passing
-g
tov
on windows, the generated files contain incorrectly formatted file paths in the#line
directives. This makes debugging through GDB+VScode harder than it has to be, as it cannot correctly map the C files to the V source code.The breakpoints are still hit, I can still use the symbol watchers. I can still see the stack trace, and tell where the breakpoint was hit through that, but it is less than convenient.
Reproduction Steps
Everything described below is happening on Windows.
v new hello
.v -g .
.%localappdata%/Temp/v_0
).#line
directive, and check file path.Expected Behavior
This is what I would expect it to output, assuming it was developed for Linux first:
Current Behavior
Notice how the drive letter is right in the middle of the path. I get this would work on Linux, because the root is just
/
on there, so it still produces a valid path. Doesn't work like that on Windows, unfortunately.Possible Solution
If on windows, strip the drive name from the path, and replace it with a forward slash, to mimic the Linux paths. Another solution would be to use absolute paths, instead of relative paths. I don't know how realistic that is, though.
Additional Information/Context
This might also be problematic for windows users trying to debug V code not on the
C:\\
drive.V version
V 0.4.1 fdabd27
Environment details (OS name and version, etc.)
Windows 10, x86_64. GDB installed through msys64. V built from source only hours ago.