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

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

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
}

Create a function definition with an attribute, such as __attribute((unused)).
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.

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

Can 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

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)

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

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

Unpause Also, when you hover over the code that uses int __attribute__((packed)) does it show int __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)

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 windowsSdkVersion appears 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.

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

Navigation Menu

Repository navigation

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

sean-mcmanus commented on Apr 1, 2019

adnandzebic commented on Jun 6, 2019

adnandzebic commented on Jun 6, 2019

maxcurzi commented on Jun 26, 2019

sean-mcmanus commented on Jun 26, 2019

maxcurzi commented on Jun 28, 2019

sean-mcmanus commented on Jun 29, 2019

maxcurzi commented on Jun 29, 2019

sean-mcmanus commented on Dec 21, 2019

sean-mcmanus commented on Dec 21, 2019

ahicks92 commented on Feb 24, 2020

Colengms commented on Feb 24, 2020

ahicks92 commented on Feb 24, 2020

Colengms commented on Feb 24, 2020

Colengms commented on Jan 14, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions