Vscode-cpptools: Intellisense not working with some 'std' members unless I specify 'using namespace std'

[ghost]

See reply below for code to easily repro

Intellisense seems to ignore certain std members unless I specify using namespace std

Example:

#include <unordered_map>
struct Font
{
    /* ...other members... */
    std::unordered_map< int, Glyph > glyphList;
};

This does not work, and VSCode will claim in my .cpp file: class "Render::Font" has no member "glyphList"
Intellisense will work for every other member in the Font struct except glyphList.

If I change the code to the following, it works perfectly fine:

#include <unordered_map>
using namespace std;
struct Font
{
    /* ...other members... */
    unordered_map< int, Glyph > glyphList;
};

By including using namespace std and removing std:: from the front of unordered_map, intellisense will correctly recognize glyphList as a member of Font.

Oddly enough, other std members such as std::string work fine and are properly recognized by intellisense without having to use the above workaround:

struct Font
{
    std::string filename; // works fine
    std::unordered_map< int, Glyph > glyphList; // not recognized as a member of Font by intellisense
};

Additionally, this will also happen if I'm including a container's header within another included file, even with the above workaround:

#include "Base.h" // contains #include <vector>
using namespace std;
struct Parts
{
    vector< int > slices; // not recognized
};

This is fixed by adding #include <vector> to the file, however not doing so still produces perfectly valid code with g++, with not even a warning. It appears as if intellisense is not recognizing includes within other included files. It however does _not_ complain that vector is undefined, so clearly it recognizes it to some extent.

This is with "C_Cpp.intelliSenseEngine": "Default" turned on.
I'm running VSCode 1.14.2, cpptools 0.12.1, and Arch Linux.

[ghost]

Here's a gif that might better help illustrate the problem:

[sean-mcmanus]

What is Render? A namespace or class/struct? I'm not able to repro the issue. If the #includes are being used inside the Render scope, you might try removing it.

[ghost]

@sean-mcmanus

I think I've narrowed it down.
Attached a zip with some minimal code that can reproduce this issue in a new clean project.
Also included my c_cpp_properties.json for reference. I've only included the relevant Linux section.

doug-intellisense-issue.zip

test.h:

#pragma once

#include <unordered_map>
#include <string>

// workaround for list2 to work
using namespace std;

struct Thing
{
    int height; // works
    std::unordered_map< int, std::string > list1; // doesn't work
    unordered_map< int, std::string > list2; // works
};

class MyClass
{
    void DoStuff();

    // if this line is removed, list1 works:
    std::unordered_map< std::string, Thing > thingList;
};

test.cpp:

#include "test.h"

void MyClass::DoStuff()
{
    Thing th;
    int a = th.height;
    int b = th.list1.size(); // class "Thing" has no member "list1"
    int c = th.list2.size();
}

This also occurs elsewhere in my project with the same fix.

• struct with an unordered_map in it
• unordered_map of that struct in a class

Commenting out the unordered_map in the class allows intellisense to recognize the unordered_map in the struct (although I of course still need the unordered_map in the class for my code to function, so this doesn't really work as a solution.) Also happens with std::vector in the same situation, not just unordered_map.

[ghost]

I have the same problem. Happens here with std::vector on Linux Mint 18.3, VS Code 1.20.1.
With using namespace std; the reported error vanishes.

[magillo]

Same here with Linux Mint and VS code 1.23.1, pretty annoying.
Any update on this issue?
using namespace is Evil if not really needed, I can't mess cross platform projects by adding them everywhere.
This is even worse if you have to share your code with others who do not use VS code thus not having these problems

[bobbrow]

@sean-mcmanus, this looks like a bug with clang mode. It works with msvc mode.

[sean-mcmanus]

@bobbrow You're able to repro this? It's not reproing for me on Linux/clang-x64 mode.

[bobbrow]

yeah, I repro on Windows with clang mode (and WSL/GCC 5).

[CelticMinstrel]

I get this on Windows (cl 2017) with variant, optional, and the entire filesystem namespace. I don't experience it with unordered_map or vector, however.

Though, the using namespace std workaround doesn't work in the case of optional or filesystem, so I suppose that might be a separate issue.

[sean-mcmanus]

@CelticMinstrel We had a bug with C++17 stuff with 0.23.0-insiders that got fixed with 0.23.0-insiders2 -- what version are you using? I'm not seeing a bug on 0.23.0-insiders2.

[CelticMinstrel]

I'm not using the insiders version at all (in fact, the constant request to switch to it is a bit irritating). I'm not sure of the exact version, but I'm pretty sure it's the latest non-insiders. In any case, it's not new; I've had this trouble probably for... at least six months, I think? I thought it might be an issue of missing macros in the cpp settings file, but I wasn't able to find any that made it work.

[sean-mcmanus]

@CelticMinstrel This issue doesn't repro for us and your report is the only one like this we have received, so we need more info to find out what is going wrong. If you can enable Debug logging and then open a .cpp file with the missing headers and see what includePaths are being used for the MSVC headers and any errors messages that could help. In particular, the version of the MSVC headers you're using is important. We also added a C/C++: Log Diagnostics command in the 0.23.0-insiders2, which is identical to the 0.23.0 we plan to ship Monday.

[ghost]

I've retested the original issue with 0.22.1 and then 0.23.0-insiders2 and everything works on both! Not sure exactly when this was fixed, likely a much earlier version. Thanks for the awesome extension.

@CelticMinstrel I believe your problem seems to be unrelated (this one was Linux specific), can you make a new issue for it? As this issue has been fixed, I will be closing it.

[CelticMinstrel]

I'll try debug logging and/or log diagnostics tomorrow morning and open a new issue (assuming 0.23.0 doesn't actually fix it). Is there an easy way to determine the MSVC headers version though?

[sean-mcmanus]

@CelticMinstrel The header version should be in the includePath used, e.g. C:/PROGRAM FILES (X86)/MICROSOFT VISUAL STUDIO/2019/PREVIEW/VC/TOOLS/MSVC/14.21.27619/INCLUDE.