Repository navigation
On Windows, both gcc/clang and MS extensions should be supported in clang mode, instead of switching to msvc mode #3387
Description
Activity
"clang-cl.exe" is somewhat unsupported currently. The problem is that the msvc headers require compilation using "msvc" mode, but that mode doesn't understand clang-specific
"__attribute__". So switching to "clang" mode would enable the"__attribute__"(if we didn't force it to msvc), but it wouldn't be able to compile the Windows headers.Reacted by dbjCan confirm same issue here..
For now I am avoiding the default "msvc" setting for the mode by specifying "gcc-x64" or "clang-x64" in settings.json:
"C_Cpp.default.intelliSenseMode": "gcc-x64"I'm also seeing a similar issue on 1.35 (it used to be fine before).
Now all structs that are defined as __attribute((packed)) are not supported anymore with the F12 lookup elsewhere in the code.
MC-8 I repro this with a C file with 0.23.1, but it appears to be fixed with our 0.24.0-insiders2 release (set your updateChannel to "Insiders").
Sean McManus (@sean-mcmanus) That worked, thanks ;)
After changing that setting (insiders3 now) and reloading everything, the parser had some hiccups in recognizing (and coloring) the uint16_t type (but all other uintx_t were correctly pointing to stdint.h) but restarting VS code fixed that. No big deal, just reporting for posterity this strange, yet one-off, behavior.EDIT: Sean McManus (@sean-mcmanus) actually, few minutes after re-opening VS code the uint16_t is still not detected.
If I select intellisenseMode: msvc-x64, the old issue (__attribute structs not recognised) re-surfaces,
but if I select gcc-x64:
#my C_Cpp settings:
"C_Cpp.intelliSenseEngine": "Default", "C_Cpp.intelliSenseEngineFallback": "Enabled", "C_Cpp.updateChannel": "Insiders", "C_Cpp.default.intelliSenseMode": "gcc-x64", (or msvc-x64) "C_Cpp.errorSquiggles": "Enabled",EDIT 2:
Also, the type colours appear to change (without changing intellisense mode) when I use the RescanWorkspace command. Not sure if this may be related
__attribute is expected to fail in msvc-x64 mode, because the cl.exe compiler doesn't support it.
Could you move the uint16_t issues to a new issue? I don't have enough info to repro it. We have 1 known bug with the IntelliSense cache sometimes causing headers to not get loaded correctly.
The insiders build added semantic colorization from IntelliSense. See https://github.com/microsoft/vscode-cpptools/blob/master/Documentation/LanguageServer/colorization.md . The enhancedColorization controls that.
Thanks, I will create a new issue for the uint16_t then once I gather more reliable reproduction steps.
Unpause It should not be -- my guess is that it's using msvc mode instead. What mode does it say is being used when you run C/C++: Log Diagnostics on with that file active?
Unpause Also, when you hover over the code that uses
int __attribute__((packed))does it showint __attribute? And what is the error squiggle you see? Does it repro only when the__attribute__is used at a particular location?I'm having the same problem. The diagnostics show that it's in msvc-x64 even if the compiler path is clang and the IntelliSense mode is explicitly set. My c_cpp_properties.json:
{ "configurations": [ { "name": "Win32", "includePath": [ "${workspaceFolder}/include/**" ], "defines": [ "_DEBUG", "UNICODE", "_UNICODE" ], "windowsSdkVersion": "10.0.18362.0", "compilerPath": "C:/Program Files/LLVM/bin/clang.exe", "cStandard": "c11", "cppStandard": "c++17", "intelliSenseMode": "clang-x64", "compileCommands": "${workspaceFolder}/build/compile_commands.json" } ], "version": 4 }i've also tried this without the compile_commands.json, and with/without the CMake configuration provider enabled, which is using Clang.
Sean McManus (@sean-mcmanus) , I believe what both alexmax and @camlorn are reporting is currently 'by design'. On Windows, if we detected clang.exe or clang-cl.exe, and detect 'Windows Kits' within it's system includes, we change the IntelliSense mode to msvc, to account for Clang having enabled support for MS language extensions. However, that means we will squiggle gcc/clang language extensions instead.
Any workaround or way to change this? My project isn't using (nor does it plan to use) Microsoft language extensions, and I don't think the CMake kits will let us work around this without customization. It seems to me that if someone is going out of their way to explicitly specify the setting, then principle of least surprise is that the setting is obeyed.
Dropping
windowsSdkVersionappears to not change anything. Is there anything else I can do? In addition to squiggles, it also puts things in the problems view, which I use rather a lot to find actual problems.- changed the title
[-]Visual Studio Code incorrectly highlights `__attribute__((foo))` syntax as a problem on Windows[/-][+]On Windows, both gcc/clang and MS extensions should be supported in clang mode, instead of switching to msvc mode[/+]on Feb 24, 2020 Hi @camlorn . If, when we query clang, it returns Windows Kits paths as system headers, it will have enabled MS language extensions. Otherwise, Windows headers would not successfully compile, and you would see squiggles from our extension that refer into system headers. Currently, you will see fewer IntelliSense issues in msvc mode than clang mode, when using clang on Windows.
I see here: https://clang.llvm.org/docs/MSVCCompatibility.html
If you don’t require MSVC ABI compatibility or don’t want to use Microsoft’s C and C++ runtimes, the mingw32 toolchain might be a better fit for your project
We suspect there may be a way we can configuring the IntelliSense engine to support both sets of language extensions. Renaming this issue to track a proper fix.
This has been fixed. We referenced #6075 when it was fixed. (I think this bug should have been used, but we overlooked it).
- locked and limited conversation to collaborators
on Mar 1, 2021
Type: LanguageService
Describe the bug
__attribute__((foo))syntax as a problem on Windows.To Reproduce
c_cpp_properties.json:__attribute((unused)).unnamed prototyped parameters not allowed when body is presentexpected a type specifierExpected behavior
I expect Visual Studio Code to not point this out as a problem, because this syntax works just fine when using clang.