Vscode-cpptools: Stop converting the "-std=c++0x" to "-std=c++11"

[ghuser404]

So I have this weird issue, my project is using gcc 4.6.3, and it looks like the compiler has a bug, that vscode rightfully gives an error about, but the code builds. It's a bit annoying and isn't cool overall. What can I do about this issue?

The bug is as follows:
I have a struct, let's say struct Foo { int id; std::unordered_set<int> set; };. My class has a private member of this struct, and it initializes it in initialization list like this : member({ 0, { } }).

The problem with this is that gcc 4.6.3 unordered_set default constructor is explicit, which is why member({ 0, { } }) gives an Intellisense error, according to C++11. However, if this was actually an invalid code, I would write member({ 0, std::unordered_set<int>{ } }) (which is subjectively less pretty), but standard actually says that unordered_set default constructor is not supposed to be explicit, and so my code builds correctly in later gcc versions.

Is my only option to either update gcc or to write ugly code just to satisfy IntelliSense?
Another option would be to ignore it, but let's not talk about this.

[sean-mcmanus]

gcc 4.6.3 appears to not fully support C++11 and only supports the c++0x flag -- is that what you're building with? If you run C/C++: Log Diagnostics with the source file active, what is reported as the "Standard Version"? I would update your compiler if possible (4.6.3 is very old). You could also try surrounding the code with #ifndef __INTELLISENSE__ to make code non-visible to IntelliSense.

The code I'm using is:

#include <unordered_set>
struct Foo
{
    int id;
    std::unordered_set<int> set;
};

class Bar
{
public:
    Bar(): member({ 0, { } }){}
private:
    Foo member;
};

It's possible our emulation of c++0x with that version of gcc is incorrect -- our parser tries to parse things the same depending on the version used.

Also, if you're using gnu versions see https://github.com/microsoft/vscode-cpptools/issues/2782 .

[ghuser404]

Yes, the project is using the c++0x flag.
C/C++: Log Diagnostics gives Standard Version: c++11.

It's possible our emulation of c++0x with that version of gcc is incorrect

Does cpptools actually take compiler version into account? If so, theoretically this could be possible to fix on the cpptools side?

our parser tries to parse things the same depending on the version used.

You mean, depending on the version [of c++ standard] used?

PS. I've actually been looking into updating the compiler, I wish it was easier than it actually is. We're building our toolchain with an old version of buildroot, and I've had some issues upgrading to a newer one. But we'll get there... eventually.

[sean-mcmanus]

Yes, our parser takes the gcc version into account. However, it looks like we are incorrectly sending our parser a c++11 flag instead of c++0x, which should be trivial for us to fix (not 100% sure that would fix your issue though, i.e. if our parser still doesn't handle it correclty).

[ghuser404]

Awesome! Let me know whenever an insider build contains this fix, I'll test it for you.

[sean-mcmanus]

Fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/0.28.0-insiders .

[ghuser404]

@sean-mcmanus I still have same error. Running C/C++: Log Diagnostics still gives Standard Version: c++11. Was this supposed to change?

[sean-mcmanus]

Make sure you have 0.28.0-insiders installed (not 0.27.1) -- we had an issue last night that prevented auto-update to 0.28.0-insiders, but it's fixed now. Also, you need to use something like "compilerArgs": [ "-std=c++0x" ], since only the published standards are available via the cppStandard setting.

[ghuser404]

@sean-mcmanus Yeah, I couldn't auto-update yesterday, so I had to manually download, but auto-update works now.

1. The problem is that I'm using "configurationProvider": "ms-vscode.cmake-tools", so I have "compilerArgs": [], and cppStandard isn't there at all. With this I get Standard Version: c++11.

2. I tried removing "configurationProvider": "ms-vscode.cmake-tools" and manually writing "compilerArgs": ["-std=c++0x"] and compilerPath to whatever compiler my CMake configuration is using. Now I see "compilerArgs": ["-std=c++0x"] in C/C++: Log Diagnostics and actually Standard Version: c++0x. Tried that on 0.27.1 and this indeed doesn't work, so fix actually works. But not for CMake, it seems.

3. Additional issue: I tried wiriting "compilerArgs": ["-std=c++98"] and I get Standard Version: c++03 in C/C++: Log Diagnostics. Should we open a separate issue for this?

[Colengms]

Hi @ghuser404 . When using cmake-tools, I suspect CMake is putting 'std' on the command line and that is taking precedence. Can you extract the command line CMake is generating? (In my case, compile_commands.json is always generated, and I can see it there). The command line from Cmake will take precendence over the custom configuration from cmake-tools (but should be the same), and those take precedence over any command line, args, or cppStandard present in c_cpp_properties.json.

[ghuser404]

@Colengc Great! I now see that CMake is appending -std=gnu++0x, and it seems because cpptools doesn't support gnu versions yet (#2782), it shows Standard Version: c++11. Now that I set set(CMAKE_CXX_EXTENSIONS OFF) in CMakeLists.txt, CMake is no longer appending -std=gnu++0x, and I correctly get Standard Version: c++0x.

However, my original issue doesn't seem to be fixed with this. I know this ticket was changed to track conversion of -std=c++0x into -std=c++11, so I guess I need to create another ticket for my original issue?

[sean-mcmanus]

@ghuser404 gnu++0x should work in 0.28.0-insiders2 (not yet released). What was your original issue? A new issue might better for tracking purposes.

[ghuser404]

@sean-mcmanus I get red squiggles when initializing std::unordered_set<int> as { } in an aggregate. See my first comment for more details.

[sean-mcmanus]

@ghuser404 Sure, I'll check on that tomorrow...

[sean-mcmanus]

@ghuser404 I'm not able to get any IntelliSense error with the code mentioned at https://github.com/microsoft/vscode-cpptools/issues/5157#issuecomment-601491249 and using https://godbolt.org/ with gcc 4.6.4 and -std=c++0x. Is my repro code insufficient to repro the bug?

[ghuser404]

@sean-mcmanus Your repro code is sufficient. ~In godbolt you will not see an error, because code builds perfectly fine, because unordered_set's header in gcc 4.6.3 in not C++11-conformant.~ Godbolt's IntelliSense must be working correctly then.

You can reproduce this with gcc 4.8.1 too. If you're on Windows, MingW-W64-builds still supports 4.8.1 http://mingw-w64.org/doku.php/download/mingw-builds

Here is my main.cpp

#include <unordered_set>

struct Foo
{
    int id;
    std::unordered_set<int> set;
};

class Bar
{
public:
    Bar(): member({ 0, { } }){}
private:
    Foo member;
};

int main()
{
    return 0;
}

Here is my c_cpp_properties.json

{
    "configurations": [
        {
            "name": "Win32",
            "compilerPath": "C:/mingw-w64/4.8.1/mingw32/bin/g++.exe",
            "compilerArgs": ["-std=c++0x"]
        }
    ],
    "version": 4
}

[sean-mcmanus]

Yeah, I repro the squiggle now. Our parser has lots of stuff handling special cases with gcc 4.8, but it looks like this case is missed. I'm looking into getting the bug forwarded...

[ghuser404]

@sean-mcmanus Sorry to bother, did you forward the bug?

[sean-mcmanus]

@ghuser404 Not yet -- it's on my TODO list (hit some unexpected delays). Hopefully tomorrow...it's not as simple as just filing a bug -- I have to build our parser in a different branch, but it's getting build errors.

[sean-mcmanus]

@ghuser404 I reproed the issue with the EDG parser and emailed the VS team...waiting to hear back from them -- they'll usually file a bug on EDG, but it's only trackable in our internal databases -- I'll use this issue to track that (i.e. removing the "fixed" label). The EDG team might be prioritizing getting C++20 stuff finished, so I'm not sure what the ETA/priority on this would be.

UPDATE: VS team replied, bug on EDG got filed.

[ghuser404]

Thanks! Let's hope they find time to look into this issue.