Repository navigation
fix: split compilation database command strings with shell quoting rules - #10
Conversation
|
I think |
cb076ef to
881a2d6
Compare
|
You are right. Fixed it with if os.name == "nt" and added the POSIX test case for -DVERSION="1.0". |
|
I suggest we do not add the |
|
pr #9 was merged. you can remove the fix commit from this pr related to the |
f2efa65 to
881a2d6
Compare
A compile_commands.json record may carry its flags as `command`, a single string the shell would have tokenized. Splitting it with `str.split()` kept the quotes, so an empty define written by CMake as `-DMACRO=""` reached libclang as the string literal `""`. A declaration starting with such a macro no longer parsed as a function and disappeared from `docs` output with no diagnostic. `shlex.split()` is not a drop-in replacement: in POSIX mode it treats the backslashes in a Windows compiler path as escapes, so `-IC:\inc` arrives as `-IC:inc`. Disabling escapes outright is wrong in the other direction, because a POSIX string define is written `-DVERSION=\"1.0\"` and those backslashes have to resolve. Drive `shlex` directly and disable escaping only on Windows, so the backslash rule follows the shell that wrote the command.
881a2d6 to
299fd51
Compare
3 participants
A compile_commands.json record may carry its flags as
command, a single string the shell would have tokenized. Splitting it withstr.split()kept the quotes, so an empty define written by CMake as-DMACRO=""reached libclang as the string literal"". A declaration starting with such a macro no longer parsed as a function and disappeared fromdocsoutput with no diagnostic.shlex.split()is not a drop-in replacement: in POSIX mode it treats the backslashes in a Windows compiler path as escapes. Driveshlexdirectly with escaping disabled instead, so quotes are stripped and backslashes stay literal.