Clang IntelliSense appearing as GCC to source

[sepehr]

Hello,

I have recently tried vgdb for the first time and I should say I am pleased with its debugging abilities and its ease of use. I have a minor problem with the Clang engine.

I have vgdb working on a huge body of source code compiled with GCC, what happens is that when Clang engine wants to parse all my sources, my sources (obviously) see it as the Clang compiler. I tried dumping all GCC preprocessor definitions and passing them to Clang but at that point Clang engine appears to just dead-lock somewhere and never finish what it needs to be doing (after half an hour of waiting).

Is there a workaround for this? So the Clang engine appear as the right compiler to my sources?

Thanks in advance

[support]

Hi,

VisualGDB normally does exactly that – captures the #define-s reported by gcc and feeds them into the Clang IntelliSense. If you are using MSBuild projects, you can see a list of those via View->Clang IntelliSense Diagnostics Console ->View->ProjectStatus->CFLAGS (due to a bug in the Windows edit control, it may appear empty if CFLAGS is too long; copy-pasting it to notepad should help). If you are using non-MSBuild projects, the flags are dumped in gcc_<configuration name>.h and this file is forcibly included by the Clang engine.

If you believe this is not happening, please let us know the details (which macros are missing from the IntelliSense point of view) and we will help you troubleshoot this.

[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.

[support]

Hi,

The _WIN32 macro should not be defined with the Clang IntelliSense. If you believe it is, please double-check it with the following code:

#ifdef _WIN32
#error Oops
#endif

If you get the error message, please try selecting ‘go to definition’ for the WIN32 macro. Perhaps it is defined on one of your header files?

The __clang__ macro is defined together with the __GNUC__ macro; as Clang is normally backwards compatible with GCC, this should not be causing any trouble.

[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.

[support]

Hi,

Could it be that this specific header file is not a part of a VisualGDB project and hence instead of using Clang IntelliSense, Visual Studio opens it with the regular IntelliSense?

You could quickly check this by checking the blue ‘go’ button on top of the source file. If it is not shown, the file is not handled by the Clang IntelliSense. If this is the case, please let us know how you navigate to that file and we will try to fix this.

[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).

[support]

Hi,

VisualGDB processes the included files together with the source, however if you have non-Clang projects in your solution and open a header file that does not belong to a Clang-based project, VisualGDB will treat this header file as a part of a different project and won’t use the Clang engine for it.

Could you try right-clicking in that header file and check if the “Preprocess selected lines” or the “Generate a graph of include files” command is shown? If you are not sure, you can simply attach a screenshot showing the context menu in that file. This should help us understand what is causing this and suggest a workaround.

[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.

[support]

Hi,

No problem. The ‘generate graph of include files’ command actually comes from the VS IntelliSense, so that header file is not recognized by VisualGDB. This could happen if your solution had both VisualGDB and non-VisualGDB projects. Is this the case? If not, how many projects does your solution have?

[Author]

Posts