[sepehr]

I do have that option enabled in the context menu (Generate a graph of include files). Sorry I cannot share a screenshot, source is confidential.

[sepehr]

This is indeed one of the main cpp files in my vgdb project tree (imported by vgdb itself). The body of the source works correctly and parsed by Clang. It’s just the pre-processor (#includes) section of the file which appears to have both _WIN32 and __CLANG__ defined. I do not know how internally VS/vgdb handles this, but it seems like both engines are trying to pre-process the source at the same time (only in the #includes section).

[sepehr]

so I double checked _WIN32, it turned out _WIN32 is only defined in the preprocessor section, and not in the source. For example the following:

#ifdef _WIN32
#include <windows.h>
#endif

I do get that include, and Clang marks it as a not found header (obviously) within my Linux source.

__clang__ and __GNUC__ defined together causes a LOT of problems with Boost automatic compiler detection headers. Boost headers all barf simply because they cannot decide whether Clang is the compiler or GCC. This is not limited to Boost, POCO is the same as well. Their auto-compiler detection features fail for the same reason.

[sepehr]

Apologies for the late response, I assumed I get an email for the reply to my thread.

There are some macros that should be undefined but they are not (such as _WIN32 or _CLANG_). I am using GCC over SSH and I expect the Clang IntelliSense to appear as GCC by defining all its macros. Instead, I have all Visual Studio, GCC, and Clang macros defined at once. I tried passing /u to the Clang engine but it is not effective.

[Author]

Posts