IntelliSense in Visual Studio 2019 with CMake Project and IAR Compiler - c++

So I have a CMake project which I open in Visual Studio 2019 with the "Open Folder" option. From here I can build and compile it without any errors (CMake is using the IAR Compiler (iccarm.exe) as specified in the toolchain file). So far so good.
The problem is that IntelliSense, despite finding all necessary header files, shows lots of errors mainly related to "undefined __INTxx_T_TYPE__".
As far as i know thouse double underscores indicate that it's a compiler internal data type, which is not defined in any header file, which would also explain why IntelliSense reports that it's not defined (even if the compiler knows the type). I guess to counter this problem, IntelliSense does support different modes like "windows-msvc-x86" or "linux-gcc-arm". But there is no option for IAR compiler.
So my question: How can I get IntelliSense running in this project ? Is there a way to add a custom IntelliSense mode for the IAR compiler ? Can i add header files only for IntelliSense in which the missing types are defined ? Is there a way to tell IntelliSense not to worry about those types / ignore the types ?


Ok just for the unlikely case someone has the same problem, here is my "solution" (sort of):
I created a header file with all the internal types used by IAR and called it "intellisenseHeader.h". You can find the internals here (https://www.gaio.co.jp/support/user/faq/winams/docs/sample_predef.pdf), but in my case i had to add some definitions by myself. The problem is now, that it won't compile anymore, because the IAR compiler, now finds 2 definitions (the internal definition and the one in the header file). So we need to fix this again:
I put the include inside a #ifdef USE_INTELLISENSE_HEADER.
I created two Visual Studio configurations. In the first one, CMake will set the preprocessor directive and the intellisenseHeader file will get included. In the other one i didn't set it.
So what's the effect of this ? If you are in the configuration, where the header is included, IntelliSense works but you can't compile. And if you are in the other one you can compile, but IntelliSense doesn't work anymore. So now i need to switch between the configurations, everytime i want to compile or write some code... Not the best solution but still better than nothing.
EDIT: Ok just realized you can use __INTELLISENSE__ as mentioned in # Richard Critten comment, and therefore don't need to use multiple configs.

Related

Visual Studio warning about copies of files with different contents

When I go to debug my C++ project in Visual Studio, up pops a little warning dialogue box that tells me:
A copy of datum.h was found in
c:/users/brad/desktop/source/binary/datum.h, but the current
source code is different from the version built into
c:/users/brad/desktop/source/binary/datum.h.
I'm having trouble understanding what this is even trying to tell me, let alone how to fix it. At first I thought it might be complaining that I'd accidentally duplicated a file in the directory, which I checked, and found nothing of the sort, which leaves me pretty stumped. I also tried excluding the file from the solution and adding it again, which didn't fix the problem either.
The warning doesn't appear to actually hinder the development of my project, but I suppose warnings exist for a reason, so if anyone knows what's gone wrong, any advice would be greatly appreciated. To my knowledge, I didn't change anything to cause the message to appear, it just popped up one time I went to debug the solution and has kept on appearing ever since.
Also, more copies of the same warning have started popping up, pertaining to other header files in my solution (I haven't recieved any about .cpp files yet, but it could be a coincidence, because it's only been going on for about 20 minutes).

Try removing breakpoints from the file in question.
This worked for me when it occurred with Visual Studio 2013 for a header file in debug build.
Source: Release mode file sync issue - current source code different from the version built
Additional notes: Clean / Rebuild also works, but that is painful for regularly changing code. Enabling the break point after starting debugger merely delays the message.

I solved it:
Close the window of the .h file in Visual Studio if it's open.
Close Visual Studio.
CUT the .h file from its normal location and paste it into a temporary folder that VS doesn't know about.
Restart VS and compile. It'll complain about the missing .h file. Good -- Make the bastard beg for it!
Paste the .h file back into its original location.
Compile. VS will gratefully accept the missing file. (Damn I hate Microsoft!)

This occurs if you rename an implementation file (*.c, *.cpp, etc.) to a header file.
This is because the Item Type still remains as C/C++ Source File, making it get compiled as a separate translation unit rather than as an actual header, preventing Visual Studio from recognizing its inclusion as a header elsewhere.
It took me quite a while to figure this out.
To fix this:
Right-click your header file in Solution Explorer and select Properties.
Select All Configurations, All Platforms.
Under General, change Item Type to C/C++ Header.
Press OK.
Force-recompile any file that #includes your header (or just Rebuild the solution).

The problem is that the debugger thinks that the checksum of the source file is different from what the compiler calculated and put in there. The debugger will then refuse to apply breakpoints in the files that mis-match, to prevent you from seeing data it can't guarantee is correct.
I have had this keep happening even after a clean rebuild. This is with VS 2015. My guess is perhaps the debugger and the compiler disagree on how to hash newlines or something like that? The fix is to turn off "require source files to exactly match the original version" in Debug -> Options -> Debugging -> General

Could you by any chance be debugging another executable (not the one actually built?). This is a common issue in scenarios where Visual Studio builds the binaries in one directory but then they are copied over to some other directory for debugging. I'd suggest you compare the target path under the debugging settings and the output directory under the general settings in Visual Studio.
This would explain the issue, since you are actually debugging some older version of the binary (not the one built currently) and thus the warning, since Visual Studio can't find the version of the source files for that version of the binary.

The reason may be circular header dependencies. datum.h may includes another_header.h (directly or indirectly), which includes datum.h.

I see the real reason of this question is not answered. So for someone still looking, here it goes...
The most common reason of this problem is that the source files used to build the existing obj files are different than the existing ones. In other words the
particular project did not build after new modifications to source. The solution to this problem is to rebuild the project after modifying.
This happened to me in situation where I had modified my static library projects files and then without building that project I started my application project which was using this static library project.

this worked for me:
close VS
delete *.vcxproj.filters file
restart VS
problem should be gone.

this worked for me:
clean project
debug/delete all breakpoints :)

This worked for me (as of March 2019):
Click the 'Build' drop-down menu in the top left of your Visual Studio window
Select 'Rebuild Solution'

I've changed the file name and it works now.

Just encountered this. In my case, one of my .h files contained implementation (a class with static methods), which was #included by one of my .cpp files, but the Project Settings were also telling Visual Studio to compile the .h file.
I manually edited both the .vcxproj and .vcxproj.filters project files, moving the .h file from the <ClCompile> ItemGroup to the <ClInclude> ItemGroup.
This did the trick for me; I never saw the "A copy of...is different from..." pop-up again.(Note that this was after I had thoroughly failed in attempts to get <DependentUpon> to work.)

My solutiion:
Build -> Configuration manager
Switch to another configuration (any, example Releas or Debug)
Switch to previous configuration

It is possible to have multiple projects, each with their own entry point within a solution. Make sure that the correct project is being run.
The source code is different message can appear in a project A's source when you are running project B. In this case, the message can mean This breakpoint won't be hit because you're running a project that doesn't include it

Visual Studio Compile Warning: Using system operator==/!= for GUIDs

I am trying to convert a Windows driver project from using the DDK build system and Makefiles into a project that can be compiled from within Visual Studio 2012.
I've followed this guide for setting up the project options, but I am getting this warning when I try to compile:
warning : Using system operator==/!= for GUIDs
I guess there is a project configuration flag that I can set that will fix this. Any help appreciated.

This is because using ==/!= on a GUID may not yield correct results, since the GUID is a non-trivial structure type.
When compiled as C++, guiddef.h implements ==/!= using this: IsEqualCLSID on MSDN
In your case, the problem is that the DDK header is unable to implement the C++ operator overloads for ==/!= GUIDs. It looks to me like this would happen because guiddef.h is being included prior to including the DDK headers. Apparently guiddef.h and the DDK don't agree on how the ==/!= operators should be implemented, and so the DDK issues a warning.
So my guess is that all you really need to do is revisit the includes order. Also, I can't verify it since I don't have VS 2012 handy, but its quite possible that this warning itself is the only thing 'new' and that the actual behavior of the program may be unchanged from VS2008. VS2008 may very well have done the same thing but failed to issue a warniner to alert the programmer. In which case, if it worked in the old compiler then it probably should work in the new one too.

From here, that warning is given by:
#if defined(_SYS_GUID_OPERATOR_EQ_)
#define _GUID_OPERATORS_
#pragma message("WARNING: Using system operator==/!= for GUIDs")
#endif
And it looks like that can be disabled by defining _NO_SYS_GUID_OPERATOR_EQ_. So try a compiler option of /D_NO_SYS_GUID_OPERATOR_EQ_.
However, I don't recommend doing something unless you know why you're doing it. Perhaps you're supposed to supply your own overloads?

Problems creating a static C++ library

Greetings fellow programmers! I am trying to create a C++ library to use in other projects. This library is to be a static library that will be linked to other projects.
Problem: The compiler doesn't seem to catch errors that it otherwise would if it were configured as an executable program under Project->Properties>General. In fact I purposely made a syntax error and the compiler
gave me a success regardless.
Is there a way to force the compiler to check everything while building a static lib?
Build Environment: Visual Studio 2010
EDIT: As it turns out, it was a rather simple, yet incredibly subtle mistake. It turns out that Visual studio was treating some of my .cpp files as header files. Because of this, the compiler was not running through the code at all (no one includes .cpp files). When adding files to the library, I must have accidentally selected header instead of C++ file. I thought Visual Studio would only rename the header file. I guess I was wrong!

This is nonsensical. It cannot happen. What is probably happening is that you think that the compiler is compiling your source file, (the one with the syntax error,) but it does not. Perhaps you have not added your source file to your project.
(Then again, C++ has a pretty quirky syntax; I hope you are sure that what you made was in fact a syntax error, and not a syntactically valid language construct.)

If you have more than one project in the workspace (solution) like exe and lib, make sure you click on the exact one to build or set it as the startup project (showing up in bold letters) if you hit the F7 button.

C++ VS Express 2010 Intellisense

I'm trying to use Visual Studio Express 2010 to write an openGL program, so It's a win32 console application. And I can't get Intellisense to show up for anything, openGL or otherwise.
What am I doing wrong, and how can I force Intellisense to show? (Like you can force the Xcode equivalent with Esc)

From MSDN:
IntelliSense can stop working under certain conditions. Use the following steps to help determine why IntelliSense does not work for C++ projects.
To investigate IntelliSense failure in C++ projects
Make sure that the Visual C++ project contains no compilation errors.
1) If the project is a Makefile project, see How to: Enable IntelliSense for Makefile Projects.
2) Make sure that stdafx.h is on the include path. For more information about include paths in Visual C++ projects, see #include Directive (C/C++) and /I (Additional Include Directories).
Also :*General, All Languages, Text Editor, Options Dialog Box
Provides information about how to turn off IntelliSense.
NB.
IntelliSense LimitationsIntelliSense does not work in C++ projects under the following circumstances: ( there more then this one below )
IntelliSense is not fully supported when you reference a header file multiple times by using the #include directive, and the meaning of that header file changes because of various macro states that are defined through the #define directive. In other words, when you include a header file several times and the header usage changes under different macro states, IntelliSense does not always work.

Please find *.sdf file in project directory and delete it relaunch the solution file. It will show your intellisense

Visual Studio incorrectly marking inactive code blocks when using `#ifdef`

My project has a bunch of #ifdefs. The macros used by these #ifdefs are usually passed through the command line using the '/D' option to get different build configurations. Visual studio incorrectly assumes that these macros are not defined and greys out the code blocks present inside these #ifdefs. The problem is not syntax highlighting - I can turn the grayed out code to colored code from Options; the main issue is that I am not able to go to the function definition of any functions present inside that #ifdef. I tried reading about Visual Studio hint files but that didn't work for me.
Can anyone help me with this issue? I am using Visual Studio 2008.

Did you define several kinds of builds within VS as Configurations like Debug, Release, or are you building with makefiles? If you haven't taught VS about your /D options then I guess it can't help you. But you should be able to set up Preprocessor Definitions under project properties (Configuration Properties, C/C++, Preprocessor) to get the effect you want, right?
For each option /DMACRO=XXX that you pass to the compiler, specify MACRO=XXX in the IntelliSense Preprocessor Definitions. For each option /DMACRO (no value) that you pass to the compiler, specify MACRO in the IntelliSense preprocessor definitions.

If you're not debugging, and you're just trying to get intellisense or whatever to react, you can always just throw up a quick #define to force the IDE to behave.
Seems you have a similar problem as this fellow:
Can intellisense be enabled in VS2008 within preprocessor directive blocks like #ifndef ... #endif