IntelliSense not working correctly with anonymous members

[Victor333Huesca]

Type: LanguageService
IntelliSense not handling anonymous union member with named unions.

Generic information

• OS and Version: Ubuntu 20.04
• VS Code Version: 1.51.0-insiders
• C/C++ Extension Version: 1.1.0-insiders3
• Tested with all other extensions disabled and it does not solve the issue.

Details of the issue
In the code sample [1] the IntelliSense recognize correctly the member i2 and c2 but neither i1 nor c1.

[1]

struct S1 {
    int i1;
    char c1;
};

struct S2 {
    struct S1;
    int i2;
    char c2;
};

This seems linked to C11 standard as well as MS extensions that both allow anonymous unions and struct in C.
Nonetheless, setting the language version to C11 does not change anything.
I tried adding -fms-extensions to either the "compilerPath" or the "compilerArgs" as suggested in #3063 which is suppose to be supported with by the cpptools since version 0.22.2-insiders. But this causes the language server to crash with the error code: Failed to read response from server: 8.

Note: when using completely anonymous struct (eg. code sample [2]) there is no issue at all.

[2]

struct S2 {
    struct {
        int i1;
        char c1;
    };
    int i2;
    char c2;
};

However, as soon as a name is given to the internal member (eg. code sample [3]), the error reappears.

[3]

struct S2 {
    struct S1 {
        int i1;
        char c1;
    };
    int i2;
    char c2;
};

Note 2: somehow, gdb has the same kind of behavior of not being able to directly access S2::i2 with code sample [1] but does allow direct access to those member with bother code [2] and [3]. The integrated debugger logically follows the same behavior.

PS: For some reason, adding the -fms-extensions to compilerArgs may sometime enable the intelliSense to recognize the S2members on hover but still fails to autocomplete and produce the same error message one the console.

[sean-mcmanus]

What compiler are you using? I'm not able to get the code below to compile with gcc 10.2 or clang 11 (with -std=c++17 -fms-extensions). What code are you using that compiles?

struct S1 {
    int i1;
    char c1;
};

struct S2 {
    struct S1;
    int i2;
    char c2;
};

int main()
{
	struct S1 s1;
	struct S2 s2;
	s2.i1;
	return 0;
}

[Victor333Huesca]

I tried with gcc 10 and 9, clang gives a warning about MS extensions but still compiles. It seams to works since quite some time.
Here is an example on compiler explorer: https://godbolt.org/z/ffq5Wj
Maybe you need to compile it as C and not C++.

[sean-mcmanus]

Oops, yeah, I was using C++ instead of C.

[sean-mcmanus]

I'm using -fms-extension and gcc 10.2, but I'm reproing the bug crash or other failures. Do you have an idea what is different with my repro and/or can you provide output from C/C++: Log Diagnostics?

[Victor333Huesca]

Mhh, looks like I did a bit too far in my intention to reduce to the minimal sample.
After some more investigation I thing I got the actual problem. The type deduction for S1 does work with fully qualified type (struct S1) but fails when using a typedef. Here is an illustration (https://godbolt.org/z/ePd9cd):

typedef struct S1_s {
    int i1;
    char c1;
} S1_t;

struct S2 {
    S1_t;
    int i2;
    char c2;
};

The absence of struct when declaring the anonymous S1_t somehow disturb the parser even if the typedef should provide the struct within it.

Although this is simple to fix in the code base, this is a valid code and at least gcc and clang do accept it.

Edit: using the typedef preceding with struct avoids the extension to crash but S1 members are not recognized.
Edit 2: this 1st one (struct with typedef) is obviously not valid C, my bad.

struct S2 {
    struct S1_t; // Not valid C
};

struct S2 {
    struct S1_s; // Works as expected, struct is specified and actual struct name is used, not the typedef
};

struct S2 {
    S1_t; // Compiles with MS extensions, not recognized by the VS parser.
};

[sean-mcmanus]

I've filed a bug on the crash on our shared VS parser at https://developercommunity.visualstudio.com/content/problem/1241877/c-intellisense-process-crashes-after-invoking-comp.html ; however, I'm not understanding the "no crash" repro for the
struct S2 { struct S1_t; };
case because I'm not getting code that compiles. Can you provide a full code sample that compiles?

[Victor333Huesca]

Tanks for the feedback!
Indeed the struct with typename does not compile, Monday morning sorry :p
Still the issue with using the typename as anonymous member that compiles but confuses the VS parser. Hopefully we will get feedback on your bug report.

[al20878]

I'm experiencing this very same kind of an issue with freshly upgraded VS Code, as the OP reported.
gcc compiles the code fine, but this enclosure in particular

struct S2 {
    struct S1;

makes intellisense mark all references to S1's members within S2 as "undefined":
for example struct "S2" has no field "i1" C/C++ (136)

I set my C standard to c17 (used to be c11, but it makes no difference) in the settings...

Version: 1.55.2 (system setup)
Commit: 3c4e3df9e89829dce27b7b5c24508306b151f30d
Date: 2021-04-13T09:35:57.887Z
Electron: 11.3.0
Chrome: 87.0.4280.141
Node.js: 12.18.3
V8: 8.7.220.31-electron.0
OS: Windows_NT x64 6.1.7601

[sean-mcmanus]

The fix is available with https://github.com/microsoft/vscode-cpptools/releases/tag/1.7.0-insiders2

[al20878]

It was closed but it still does not work correctly.

This is the program:

struct S1 {
    int i1;
    char c1;
};

struct S2 {
    struct S1;
    int i2;
    char c2;
};

int main()
{
    struct S2 s2;
    s2.i1 = 0;
    s2.c1 = 0;
}

VS Code is fresh, 1.61 on Windows. Compiler is configured to be C:\cygwin64\bin\gcc.exe (from Cygwin). Note that this compiler does not need the -fms-extensions option as it is turned on implicitly by default. When VS Code starts, intellisense (1.7.0) reports that the compilation mode was changed to Linux based on the compiler (which is not exactly correct).

[10/15/2021, 10:07:03 PM] For C source files, IntelliSenseMode was changed from "windows-gcc-x64" to "linux-gcc-x64" based on compiler args and querying compilerPath: "C:/cygwin64/bin/gcc.exe"

Then these appear as "Problems":

struct "S2" has no field "i1" C/C++(136) [15,8]
struct "S2" has no field "c1" C/C++(136) [16,8]

Note that when the compiler task is run, the program compiles without any errors (there's only a warning that s2 is not used).

Can this please be really fixed?

[al20878]

Local (i.e. from the .vscode directory) c_cpp_properties.json:

 "configurations": [
        {
            "name": "Win32",
            "includePath": [
                "${workspaceFolder}/**",
                "C:/Cygwin64/usr/include/**",
                "C:/Cygwin64/lib/gcc/x86_64-pc-cygwin/11/include/**"
            ],
            "defines": [
                "_DEBUG",
                "UNICODE",
                "_UNICODE",
                "_GNU_SOURCE=1",
                "__CYGWIN__"
            ],
            "windowsSdkVersion": "10.0.17763.0",
            "compilerPath": "C:/cygwin64/bin/gcc.exe",
            "cStandard": "c17",
            "cppStandard": "c++17",
            "intelliSenseMode": "windows-gcc-x64"
        }
    ],
    "version": 4
}

local tasks.json:

{
    "tasks": [
         {
            "type": "cppbuild",
            "label": "C/C++: gcc.exe build active file",
            "command": "C:/cygwin64/bin/gcc.exe",
            "args": [
                "-Wall",
                "-g",
                "${file}",
                "-o",
                "${fileDirname}\\${fileBasenameNoExtension}.exe"
            ],
            "options": {
                "cwd": "C:/cygwin64/bin"
            },
            "problemMatcher": [
                "$gcc"
            ],
            "group": "build",
            "detail": "compiler: C:/cygwin64/bin/gcc.exe"
        }
    ],
    "version": "2.0.0"
}

P.S. Adding "-fms-extensions" to the "args" above does not help (but gcc runs without issues).

[Colengms]

Hi @al20878 . Thanks for pointing this out. There are multiple issues here. The crash issue has been fixed. But, you are correct, there is still an issue where not all members are available for completion. I've reopened the issue against VS internally.

[merlynomsft]

We're tracing the issue where not all members are available for completion here: https://developercommunity.visualstudio.com/t/CPP-file-shows-incorrect-member-list-o/1565421. Thank you for the report!

[Victor333Huesca]

Hi, I saw the issue mentioned by @merlynomsft has been marked as resolved.
I believe this issue was misunderstood and closes a bit too quickly. I commented there with further details on why this issue is still unresolved.

Feel free to upvote so the issue can be reopened.

[Colengms]

Note that this compiler does not need the -fms-extensions option as it is turned on implicitly by default. When VS Code starts, intellisense (1.7.0) reports that the compilation mode was changed to Linux based on the compiler (which is not exactly correct).

Hi @al20878 . It looks like the issue here is that the C/C++ extension does not automatically enable MS extensions for Cygwin's gcc. Apparently (based solely on trying some MS extensions), Cygwin's gcc will enable MS extensions by default, despite not outputting the (required) define associated with that behavior: _MSC_EXTENSIONS

I'm able to work around that issue, and resolve IntelliSense squiggles with the repro code, by specifying the following in c_cpp_properties.json:

            "compilerArgs": [
                "-fms-extensions"
            ]

It's by-design that using Cygwin's gcc will result in changing the IntelliSense mode to linux. Cygwin's gcc returns the define __unix, and does not return expected defines for Windows compilation. It's intended to be used to build code that targets unix and run that code in an emulated unix environment on Windows. It's not intended for compiling code specifically targeting Windows. (It may be possible to specify another target to Cygwin's gcc. The C/C++ Extension should set the IntelliSense mode properly for whatever is being targeted, based on the defines the compiler returns when the specified compilerArgs are passed to it).

You might consider installing MinGW. It can be installed within Cygwin, separately, or as part of MSYS2. MinGW is a better option if targeting Windows natively.

I believe the original problem this issue was tracking (the crash) has been resolved. I opened another issue for what remains: #8353