On Windows, both gcc/clang and MS extensions should be supported in clang mode, instead of switching to msvc mode

[leximayfield]

Type: LanguageService
Describe the bug

• Window 17763
• VS Code 1.32.3
• C++ 0.22.1
• Visual Studio Code incorrectly highlights __attribute__((foo)) syntax as a problem on Windows.

To Reproduce

1. Use the following c_cpp_properties.json:

{
    "configurations": [
        {
            "name": "Win32",
            "includePath": [
                "${workspaceFolder}/**"
            ],
            "defines": [
                "_DEBUG",
                "UNICODE",
                "_UNICODE"
            ],
            "windowsSdkVersion": "10.0.17763.0",
            "compilerPath": "C:/Program Files/LLVM/bin/clang-cl.exe",
            "cStandard": "c11",
            "cppStandard": "c++17",
            "intelliSenseMode": "clang-x64"
        }
    ],
    "version": 4
}

2. Create a function definition with an attribute, such as __attribute((unused)).
3. Note the error messages that appear around the attribute. For me, I saw the following error messages:

• unnamed prototyped parameters not allowed when body is present
• expected a type specifier

Expected behavior
I expect Visual Studio Code to not point this out as a problem, because this syntax works just fine when using clang.

[sean-mcmanus]

"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.

[adnandzebic]

Can confirm same issue here..

[adnandzebic]

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"

[maxcurzi]

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.

[sean-mcmanus]

@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").

[maxcurzi]

@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 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

[sean-mcmanus]

__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.

[maxcurzi]

Thanks, I will create a new issue for the uint16_t then once I gather more reliable reproduction steps.

__attribute__((packed)) still shows as error for me, even if i set the intellisensemode to "clang-x64" or "gcc-x64"

[sean-mcmanus]

@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?