IntelliSense(?): Error reading file paths which include whitespaces

[KarateBrot]

Type: LanguageService

---

Describe the bug

• OS and Version: Windows 8.1
• VS Code Version: 1.32.3
• C/C++ Extension Version: 0.22.1

---

The issue

The C/C++ output of my project tells me:

Failed to query default include paths and defines for C:/Users/Jan. WSL not detected
Failed to query default include paths and defines for C:/Users/Jan. WSL not detected

Notice that the path gets cut off after a whitespace. The actual path should read something like

C:/Users/Jan Post/.platformio/packages/toolchain-xtensa/bin/xtensa-lx106-elf-gcc.exe

I guess while parsing the file path in a function somewhere, the string gets terminated after encountering a whitespace.

I encountered the same issue in the previous cpptools version but there were a lot more errors concerning strings that got terminated after whitespaces. So they are fixed now. (Thanks a lot!)

Now only these two error messages are left. So somewhere there is still a function that chops away a part of my file path.

---

To Reproduce

• You need to have a Windows user name including a whitespace to reproduce.

[sean-mcmanus]

Are you passing args in the compilerPath? You need to surround the compiler part of the compilerPath with \" if you provide args afterwards, e.g. "compilerPath": "\"C:/Users/Jan Post/.platformio/packages/toolchain-xtensa/bin/xtensa-lx106-elf-gcc.exe\" -std=c++17"

[KarateBrot]

Now that you speak of it... I am using another extension called PlatformIO which auto configures c_cpp_properties.json for me. And in there I can see args being passed:

"compilerPath": "C:/Users/Jan Post/.platformio/packages/toolchain-xtensa/bin/xtensa-lx106-elf-gcc.exe -mlongcalls -mtext-section-literals"

So I guess this is a bug being produced by the platformIO extension. I will address it there. Thank you for finding the missing piece.

[sean-mcmanus]

@KarateBrot Yeah, just tell them to add the \" around the path (which is only necessary when the path has spaces and args are also used, but always using \" doesn't hurt). We'll add a squiggle in our next release so that it's easier for users to discover this error: #3358 .

It might be possible for us to later change our code to not require the \" but it's not a high priority for us to change.