Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows path separators in compile_commands.json not parsed correctly #1020

Closed
z2oh opened this issue Jan 10, 2024 · 1 comment · Fixed by #1028
Closed

Windows path separators in compile_commands.json not parsed correctly #1020

z2oh opened this issue Jan 10, 2024 · 1 comment · Fixed by #1028

Comments

@z2oh
Copy link
Contributor

z2oh commented Jan 10, 2024

Windows path separators in compile_commands.json are not parsed correctly in splitShellEscapedCommand. Following the comment there to clang's unescapeCommandLine(), it seems clang has implemented Windows specific parsing.

There's a separate bug in Swift CMake that generates incorrect path separators on Windows, but after that is fixed I expect the entries in the compilation database to look like:

{
  "directory": "C:\\path\\to\\build",
  "command": "C:\\path\\to\\swiftc.exe <snip>,
  "file": "C:\\path\\to\\build\\filename.swift",
  "output": "path\\to\\filename.swift.obj"
}

These are single-escaped JSON backslashes, which are unescaped twice (once by JSON parsing, once in the function linked above), resulting paths like C:pathtobuildfilename.swift being passed to sourcekitd. If I manually change these paths in compile_commands.json to double-escaped backslashes (\\\\) or forward slashes, the paths are interpreted as expected.

@ahoppen
Copy link
Collaborator

ahoppen commented Jan 10, 2024

Tracked in Apple’s issue tracker as rdar://120809063

ahoppen added a commit to ahoppen/sourcekit-lsp that referenced this issue Jan 17, 2024
Previously, we were splitting command line arguments on Windows using the same rules as on Unix, which was incorrect, most importantly because backslashes in the first component of a Windows command line invocation are not escaping anything but interpreted verbatim.

Fixes apple#1020
rdar://120809063
ahoppen added a commit to ahoppen/sourcekit-lsp that referenced this issue Jan 17, 2024
Previously, we were splitting command line arguments on Windows using the same rules as on Unix, which was incorrect, most importantly because backslashes in the first component of a Windows command line invocation are not escaping anything but interpreted verbatim.

Fixes apple#1020
rdar://120809063
ahoppen added a commit to ahoppen/sourcekit-lsp that referenced this issue Jan 18, 2024
Previously, we were splitting command line arguments on Windows using the same rules as on Unix, which was incorrect, most importantly because backslashes in the first component of a Windows command line invocation are not escaping anything but interpreted verbatim.

Fixes apple#1020
rdar://120809063
z2oh pushed a commit to z2oh/sourcekit-lsp that referenced this issue Feb 1, 2024
Previously, we were splitting command line arguments on Windows using the same rules as on Unix, which was incorrect, most importantly because backslashes in the first component of a Windows command line invocation are not escaping anything but interpreted verbatim.

Fixes apple#1020
rdar://120809063
ahoppen added a commit to z2oh/sourcekit-lsp that referenced this issue Feb 1, 2024
Previously, we were splitting command line arguments on Windows using the same rules as on Unix, which was incorrect, most importantly because backslashes in the first component of a Windows command line invocation are not escaping anything but interpreted verbatim.

Fixes apple#1020
rdar://120809063
ahoppen added a commit to z2oh/sourcekit-lsp that referenced this issue Feb 1, 2024
Previously, we were splitting command line arguments on Windows using the same rules as on Unix, which was incorrect, most importantly because backslashes in the first component of a Windows command line invocation are not escaping anything but interpreted verbatim.

Fixes apple#1020
rdar://120809063
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants