Designated initializer for struct with embedded struct shows missing field

[pa-eidam]

Type: LanguageService
Designated initializer for struct with embedded struct shows missing field but shouldn't.

• OS and Version: Windows 7
• VS Code Version: 1.25.1
• C/C++ Extension Version: 0.17.7
• gcc (i686-posix-dwarf, Built by MinGW-W64 project) 6.1.0

To Reproduce
Save following code as c file:

struct foo {
    int x;
};

struct bar {
    struct foo;
    int y;
};

int main() {
    struct bar bar = {.x=12, .y=13};
}

Shown message:

The code compiles and runs though.

Expected behavior
No missing field message shown.

[sean-mcmanus]

Thanks for reporting this. It's a bug/deficiency with our parser in gcc/clang mode (msvc-mode works, but that assumes you're using cl.exe to compile, so you wouldn't want to use that). I've requested a bug report be filed for this.

[sean-mcmanus]

That code doesn't build with the "normal" gcc compilers (see https://gcc.godbolt.org/ ), but it does compile with the mingw64 and strawberryperl...do you happen to know what default flags are being used with that version of gcc that could lead to the different compilation behavior? I assume they're enabling some gcc extension by default? I'm trying to figure out how to get the other gcc compilers to compile that code.

[sean-mcmanus]

Figured it out -- the gcc mingw-64 compiler has -fms-extensions enabled by default (using -fno_ms_extensions gets the compiler to fail). I'm still investigating a potential workaround...

[sean-mcmanus]

Adding "--ms_extensions" to the msvc.64.intel.clang.json file (next to the binary, i.e. .vscode\extensions\ms-vscode.cpptools-0.17.7\bin) is a workaround, but the IntelliSense process will crash if you hover over the .x (due to bug #2370, which should be fixed in our next release), so avoid that. Also, you need to make sure the file is being interpreted as "C" file (won't work with C++), i.e. it should say "C" in the bottom right.

e.g. it should look like:

      "8",
      "--ms_extensions"

[pa-eidam]

Thanks for investigating the issue. I wasn't aware that this syntax is not part of the c standard. It's nice that the cpptools might support it in the future anyway.

[pa-eidam]

Should I close the issue as it's looks more like a feature request now (support for ms extensions in the gcc compiler)?

[sean-mcmanus]

Adding support for -fms-extensions and -fno-ms-extensions args to the compilerPath and respecting mingw's default of -fms-extensions has already been implemented and should be in our next release. You can close the issue if you want or keep it open and we'll close it when we ship 0.17.8.

[sean-mcmanus]

Fixed with 0.18.0.