Sometimes VS autos/locals/watches break and instead of variables/values all I have is different kinds of:
CXX0029: Error: not struct pointer
CXX0033: Error: error in OMF type information
CXX0072: Error: type information missing or unknown
CXX0025: Error: operator needs class/struct/union
Rebuilding project, cleaning PDB/NCB etc doesn't solve it. What can I do?
Look at this Microsoft support note on: FIX: CXX0033 Error in OMF Type from Forward Class Declaration
Once you fix the PCH problem cited in the support note, I think all your errors will go away.
There is in fact a solution that lets you keep using precompiled headers: check out this more recent KB article and the documentation of the /Yl switch - which seems specifically tailored to this error.
Just add to the stdafx.cpp (or your own custom /Yc file) command line '/Ylxxxx', where xxxx stands for an arbitrary function name in your lib.
I recently faced symptoms identical to yours (in VS2010), and that solved it for me.
Are you trying to debug the "release" build? If so, many local variables will not exist as "debuggable" elements. You can get around this (if you must debug the release build) by debugging at the assembly level and look at the register values (vs. stack values, where auto/local would be in the debug build) and cast them appropriately in the "watch window".
Otherwise, build the Debug build and debug that build version. You'll get assertions where preconditions are not met, relevant/irrelevant stuff dumped to your output window, and more straight-forward debug single stepping.
It helped me to switch from using a program database (/ZI) to "c7 compatible" (/Z7). Switching off precompiled headers did not make a difference. Neither did rebuilding.
Related
While compiling on x64 plattform I am getting following error:
c:\codavs05\hpsw-sc\ovpacc\tools\codaaccesstest\coda_access.cpp(1572): fatal error C1001: An internal error has occurred in the compiler.
(compiler file 'f:\dd\vctools\compiler\utc\src\p2\sizeopt.c', line 55)
To work around this problem, try simplifying or changing the program near the locations listed above.
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information
------ Build started: Project: asyncexample, Configuration: Release Win32 ------
If I change settings to preprocessor file (Yes) i am not getting any error.
About my environment: Upgrading Microsoft Visual Studio 2005 to 2010
Please help.
I have had this problem with VS2015 while building locally in Windows.
In order to solve it, I deleted my build folder (Output Directory as seen in Properties/General) and rebuilt the project.
This always seems to help when strange things happen during the build.
I’ve encountered this error many times in VC++. Do the following steps. They’ve sometimes helped me with this issue:
Take a look at the exact location, pointed out by compiler error.
Find any external types or classes used there at that location.
Change the order of “include path” of those files found in step 2 and rebuild the solution.
I hope that help !!!!
I am getting same error with VC2012. Setting up the project properties Optimization to Disabled (/Od) resolved the issue.
In my solution, i've removed output dll file of the project, and I've made project rebuild.
I encountered the same error and spent quite a bit of time hunting for the problem. Finally I discovered that function that the error was pointing to had an infinite while loop. Fixed that and the error went away.
In my case was the use of a static lambda function with a QStringList argument. If I commented the regions where the QStringList was used the file compiled, otherwise the compiler reported the C1001 error. Changing the lambda function to non-static solved the problem (obviously other options could have been to use a global function within an anonymous namespace or a static private method of the class).
I got this error using boost library with VS2017. Cleaning the solution and rebuilding it, solved the problem.
I also had this problem while upgrading from VS2008 to VS2010.
To fix, I have to install a VS2008 patch (KB976656).
Maybe there is a similar patch for VS2005 ?
I got the same error, but with a different file referenced in the error message, on a VS 2015 / x64 / Win7 build. In my case the file was main.cpp. Fixing it for me was as easy as doing a rebuild all (and finding something else to do while the million plus lines of code got processed).
Update: it turns out the root cause is my hard drive is failing. After other symptoms prompted me to run chkdsk, I discovered that most of the bad sectors that were replaced were in .obj, .pdb, and other compiler-generated files.
I got this one with code during refactoring with a lack of care (and with templates, it case that was what made an ICE rather than a normal compile time error)
Simplified code:
void myFunction() {
using std::is_same_v;
for (auto i ...) {
myOtherFunction(..., i);
}
}
void myOtherFunction(..., size_t idx) {
// no statement using std::is_same_v;
if constexpr (is_same_v<T, char>) {
...
}
}
I had this error when I was compiling to a x64 target.
Changing to x86 let me compile the program.
Sometimes helps reordering the code. I had once this error in Visual Studio 2013 and this was only solved by reordering the members of the class (I had an enum member, few strings members and some more enum members of the same enum class. It only compiled after I've put the enum members first).
In my case, this was causing the problem:
std::count_if(data.cbegin(), data.cend(), [](const auto& el) { return el.t == t; });
Changing auto to the explicit type fixed the problem.
Had similar problem with Visual Studio 2017 after switching to C++17:
boost/mpl/aux_/preprocessed/plain/full_lambda.hpp(203): fatal error C1001: An internal error has occurred in the compiler.
1>(compiler file 'msc1.cpp', line 1518)
1> To work around this problem, try simplifying or changing the program near the locations listed above.
Solved by using Visual Studio 2019.
I first encountered this problem when i was trying to allocate memory to a char* using new char['size']{'text'}, but removing the braces and the text between them solved my problem (just new char['size'];)
Another fix on Windows 10 if you have WSL installed is to disable LxssManager service and reboot the PC.
I have a __forceinline function that cannot be inlined when compiled as CLI (probably due to the specific restrictions to inlining that apply with .NET).
In debug, it is a warning and does not prevent me from building. But in release, it comes up as an error:
error C4714: function '...' marked as __forceinline not inlined
In the project configuration, Treat Warnings As Errors is set to No (/WX-), Treat Specific Warnings As Errors is empty (no value and no inherited value) and there is no /We option in the Command Line of the C/C++ section.
Thus, I don't understand why this warning comes up as an error.
And as it is an error it prevents me from building the project in release.
Do you have any clue on why this comes up as an error?
Any idea of how I could get rid of it, considering I cannot change the function nor its use (it comes from a library I'm using and I'd like not to alter)?
Thank you very much!
In an Xcode project, I'm getting a weird warning. What is it and is it a bad thing?
Here's the warning:
Project 'Little Hoot' - Enable Recommended Warning
This will enable the following recommended compiler warning:
Suspicious Moves
It is also recommending I updated another setting too.
Target 'Little Hoot' - Update C++ Standard Library
The 'libstdc++' C++ Standard Library is deprecated. This will update the setting for Target 'Little Hoot' to 'Compiler Default', which is the recommended value.
I have looked online and I'm unable to find an answer for at least the first warning.
The "Suspicious Moves" Project/Target setting seems to control the -Wmove compiler warning optionin LLVM/Clang, which is a group of 3 other warning options: -Wpessimizing-move, -Wredundant-move and -Wself-move.
Those options generate these warnings:
warning: moving a temporary object prevents copy elision
warning: moving a local object in a return statement prevents copy elision
warning: redundant move in return statement
warning: explicitly moving variable of type A to itself
(From the Clang documentation at http://clang.llvm.org/docs/DiagnosticsReference.html)
So it's probably not a big deal whether you accept the recommendation and enable the warning, or go without it. You just won't be told if you make things slower with those suspicious moves.
I also got this message from Xcode recently while setting up a new project. My steps were removing the reference from files (such as Info.plist), creating folders directly on Finder, and adding files back to Xcode. I suppose it's a security feature but if your case is like mine, it's only a warning.
Both of these warnings refer to settings in your project not reflecting the recommended defaults. They were probably both triggered after you upgraded your version of Xcode or imported an old project into a later version of Xcode.
Unless you have good reasons to do otherwise, it is best to follow the recommendation. The easiest way to do that is click in the yellow triangles that accompany the warnings and allow Xcode to make the appropriate changes to the settings.
You should turn all warnings on, with the exceptions of pedantic warnings, unused parameters, and auto-synthesised properties; these three warnings warn for tons of good code. Same for static analyser warnings.
Then you look at what warnings you get and fix them. If you haven't done this before, then I'll estimate that 20-40% of all warnings are actual bugs in your code.
You’ll be able to see warning detail in issue navigator section. You can fix it by selecting issue. This will show an alert stating necessary changes to be done in project settings.
Click on Perform Changes button. This will make necessary changes in Project settings and thereby removing this warning.
I tried to link a library (let's call it LibB) to a program (TheProgram) that already linked another library (LibA).
The debug configuration builds fine, but in release mode I get this error:
error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MTd_StaticDebug' in TheProgram.obj
I thought that's easy to fix, because I only need to make sure that each of the linked objects are built with /MT. I did, and they all are. I also checked if there are any per-file settings that have the runtime flag differently in this configuration - there aren't. Also checked the final command line in the build - it's /MT everywhere.
Even more interestingly, if I link the debug version of LibB (while building the Release configuration), this error disappears, but I get other errors.
What could cause the mismatch despite the matching flags everywhere?
This drove me crazy and took days to discover. I wanted to share this here, because there is an abundance of questions where the problem is actually mismatching /M* flags, but that was not the case here.
The mistake was that I added a new preprocessor define in Debug mode, then copied over the whole field to the Release configuration (not wanting to fiddle with the mouse selection). This field contained _DEBUG (instead of NDEBUG) and that caused the linker to detect that /MTd was being linked. When I changed _DEBUG to NDEBUG in the Preprocessor Definitions in Release mode, the problem was solved.
As a side note, I tried to find the error in git diff, because I had a pretty good idea which commit introduced it, but it was very hard to see without a word-by-word diff due to the nature of the VS project file format. One colleague spotted this define for me, but he also pointed me to this answer about highlighting word differences in git diff, I think this can be very useful to find problems like this.
I'm creating a project with openframeworks (the full source is here: https://github.com/morphogencc/ofxAsio/tree/master/example-udpreceiver), and the empty project seems to compile fine.
I added the ASIO library, and a few header classes, and now the project seems to be give me the following error:
1>------ Build started: Project: example-udpreceiver, Configuration: Debug x64 ------
1> main.cpp
1>cl : Command line error D8049: cannot execute 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\c1xx.dll': command line is too long to fit in debug record
1>cl : Command line error D8040: error creating or communicating with child process
I couldn't find any examples of error D8049 on stackoverflow or even on Microsoft's pages, and google turned up painfully few results. The only remotely useful one was this github issue:
https://github.com/deplinenoise/tundra/issues/270
But I'm still not sure what's causing the problem. Is anyone familiar with this error, and can recommend a method for troubleshooting what's causing it?
thanks in advance!
For me, working with UE4, this was an intermittent error.
I added "bLegacyPublicIncludePaths = false;" to the innermost block of project.Build.cs and recompiled without errors.
Then I removed that line and compiled again w/o errors.
The error message suggested adding "DefaultBuildSettings = BuildSettingsVersion.V2;" to project.Target.cs which worked.
This is a bit of a weird sounding error, as it is from essentially internally generated data. However, you do have control over that. Taking the error message at face value, you probably have many/lots of defined symbols passed in on the command line (or the the ones you do have have lengthy definitions), or you may have some lengthy file paths.
If you look under the project properties, one of the selections under the C++ section is "Command Line", which will show you exactly what gets passed to the compiler. When you view that you can see where you have many or lengthy parameters, and then make changes to shorten them.
Too many defines? Put them in a header (possibly stdafx.h) and include them that way.
Long file paths? Shorten the paths, put the files somewhere else, or set up file system aliases to your real directories that use shorter paths.