squigglies on boost::promise

[therealkenc]

For the likes of me I can't get cpptools to recognize boost::promise. This is on Win32, 1.13-insider, cpptools 0.11.2. c_cpp_properties.json seems to be okay. The boost header files are recognized -- there are no squigglies on the #includes. Other boost stuff, say boost::thread is recognized. The exact same setup magically works fine in Visual Studio; heck I have them both up simultaneously on the same folder. So I am stumped on something that is probably going to be obvious.

#define BOOST_THREAD_PROVIDES_FUTURE
#define BOOST_THREAD_PROVIDES_FUTURE_CONTINUATION
#include <boost/thread.hpp>
#include <boost/thread/future.hpp>

int main(int argc, char * argv[])
{
    boost::thread t;        // <-- okay
    boost::promise<int> p;  // <--- squiggles: identifier "promise" is undefined
    return 0;
}

[therealkenc]

I deleted everything in ...AppData/Roaming/Code* and reinstalled VSCode + cpptools from scratch, and all seems well. Wonder why/how it could find boost::thread but not boost::future though. If it failed on both that would make sense. I didn't change anything in the project directory (c_cpp_properties.json or otherwise). Shrug, no biggie. Closing.

[sean-mcmanus]

Is your IntelliSenseEngine setting set to Default or "Tag Parser"? It needs to be "Default" to get squiggles to appear at all.

[therealkenc]

Set as "Default". The problem was that I was getting squiggles on boost::promise<int>, even though the code is valid. For some reason it was not picking up promise from <boost/thread/future.hpp> (where it is defined). Squigglies were working correctly otherwise, even on boost::thread, which is defined in <boost/thread.hpp>. Which is to say, the include paths were set up correctly.

That was (and still is) the unexplained part. So maybe just stash in the back of your head in case someone else hits something like it. Reinstalling everything (which is cheap) fixed the problem, but I don't know why. Maybe it had to do with wiping out and rebuilding .browse.vc.db, but I wouldn't know.

[bobbrow]

I tried out your sample code and BOOST_NO_EXCEPTIONS is getting defined somewhere, so all of future.hpp is in an inactive preprocessor block. I'm looking to see where it is getting defined.

[bobbrow]

Adding "_CPPUNWIND=1" to the "defines" array in your c_cpp_properties.json fixes the issue on Win32. We can get this added to the default set of defines (e.g. msvc.64.intel.json) to make IntelliSense for Boost work better by default. I imagine most users are going to want exception support.

[therealkenc]

Thank you. I have the following below in my c_cpp_properties.json. But note I added those before the reinstall, and do not have _CPPUNWIND=1 presently. And yet it works. Maybe those BOOST_THREAD_ defines are picking up _CPPUNWIND=1 somehow (I haven't checked). I just wanted to clarify for you that it is in fact working here now. I'll add _CPPUNWIND=1 as well just to be safe (if safe is the word).

            "defines": [
                "_DEBUG",
                "BOOST_THREAD_PROVIDES_FUTURE",
                "BOOST_THREAD_PROVIDES_FUTURE_CONTINUATION"
            ],

Thanks again for the follow-up even though I closed the issue. Appreciated.

[therealkenc]

One more data point, which might help explain this, since you were kind enough to follow up. In my Visual Studio 2017 project, I am using the new "Folder" feature and cmake. My CMakeLists.txt sets the /EHsc flag on the cl.exe compiler. So over there _CPPUNWIND=1 is getting defined automagically. But with cpptools, you have no idea I have done that in my CMakeLists.txt. Which is nonobvious but understandable. Mystery solved I think.

[bobbrow]

Thanks. Sorry for the confusion. CMake support is on our backlog, but not implemented yet.

[therealkenc]

Maybe it would make sense (and I hope I am not talking out of my butt here) to allow flags that would otherwise be defined in msvc.64.intel.json to be passed though from c_cpp_properties.json. Adding seamless support for cmake would be awesome, simply because that is what I use, but maybe someone is using another meta-build system like Google's gn, and you can't please everyone. So for example, say I might have the experimental /await flag set on cl.exe. Someone else might not, in which case they'd expect squigglies on co_await, because that isn't a C++17 operator (yet). Just a thought.