I'm getting the following (probably) inspection warning in CLion: warning: bitwise operation between different enumeration types is deprecated
There is no context menu option to disable it and I can't find it anywhere in the settings. I can see the warning popup window (see screenshot) when I hover over it with the mouse, but there isn't any information there except the warning text (no error code, intention name or anything at all that gives me a clue as to where this warning comes from)... very strange.
I thought it comes from C++20 compiler warning C5054 from the MSVC compiler so I tried to disable it in CMake with target_compile_options(engine PRIVATE -wd5054) but it didn't work.
Note: it bothers me since it appears all over my code and I fix the original code that causes it since it comes from in an external library.
Any idea how do I disable this annoyance?
Related
According to cppreference [[deprecated("message string")]] we should be able to use the symbol but in VS results in error instead.
For example I wan't to issue a warning for ANSI methods in UNICODE builds and vice versa:
#ifdef UNICODE
[[deprecated("This method does not work well in UNICODE builds")]]
#endif // UNICODE
void f() {}
compiler doesn't let me compile, but standard says the attribute should allow usage but issue a warning message.
How to resolve this?, btw. my project is set to maximum conformance with the standard.
What ever the reason for VS going against the standard, is there a better way to issue a warning for above case?
Very much late to the party, but this cost me a couple of hours this morning.
By default, Visual Studio and the sdl (Security Development Lifecycle) compile flag treat
[[deprecated]] as an error. Whether or not you agree with this or not, that's how they do it.
To fix this go to Configuration Properties -> C/C++ -> Command Line and add /sdl /w34996
The /wX part represents the severity of the warning, and the rest is the error you want to report as a warning.
I hope this saves people some time.
I was able to get the compiler to treat [[deprecated]] as a warning by adding
/w34996
to the compiler options, as suggested in the responses in following link
https://developercommunity.visualstudio.com/content/problem/786502/cant-treat-deprecated-warning-as-warning-with-wx.html
is there a better way to issue a warning for above case?
There's no other way of warning about usage of a function than deprecation attribute in standard C++ at least that I know of.
Msvc has other alternatives such as #pragma deprecated(f), but those are not better.
How to resolve this?
Assuming you haven't configured your compiler to treat warnings as errors, you could proceed with writing a bug report to the maintainers.
I haven't tested it with Visual Studio, but in my case the following helped and probably is more generic:
On that error usually warnings are treated as errors with the compiler flag -Werror, that is automatically set in Visual Studio. That is the reason way a class or function marked with [[deprecated]] results in an error. To avoid explicitly that error and output it just as a warning, the compiler flag -Werror -Wno-error=deprecated-declarations can be set. In CMake it would look like:
add_compile_options(-Werror -Wno-error=deprecated-declarations)
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 am trying to eliminate the warnings in my project so I can turn on the flag that treats warnings as errors. The project uses the boost library, specifically the Concept_check.hpp and cuthill_mckee_ordering.hpp files. The warnings 4510 and 4610 are shown in the concept_check.hpp file and I have tried to disable them using #pragma warning push and pop. The warnings are caused by the boost library trying to instantiate a class using the template found in concept_check.cpp when there is no constructor written for it.
My Question is this: Is there a more sure fire way that I can disable these warnings without modifying the boost code? I am using Visual studio 2010.
Perhaps you are looking in the wrong direction. As Alan Stokes pointed out, the warning is there for a reason. I have three hints that are perhaps not the answers you expect, but may bring an acceptable solution:
Instead of silencing the warning, just fix the error. I don't know your code, but there are other people that had a similar problem which was possible to fix by just declaring a variable.
Another question is: why do you want to turn all your warnings into errors? Is it really neccessary? I agree that normal code should always compile without warnings. But these warnings are not originating from your own code. Consider a static code-checker that warns you about issues where your compiler is blind about.
If you have to use -WX, move the offending code into a static object/library/module so you will be bothered about the warning only when you need to recompile this module. You could use specific compile options for this module, to get the warnings completely out of your way.
There is another possibility, but I'm not able to check whether it really works. According the Microsoft Documentation it is possible to set the warning level of specific warnings. (there are similar options for GCC). First, switch all warnings to error:
/WX
Then, set the warning level of the two offending warnings to zero:
/W04510 /W04610
A complete commandline would look like this:
cl source.cpp /WX /W04510 /W04610
The best solution would be to combine this with hint 3 above. This way, the specific compiler options are only used for the files that cause the warnings.
Maybe these solutions work.
You can disable specific warning from a .h file (#pragma warning( disable: ... ).
I can get rid of the warnings in the build log by adding -std=c++0x to "other c++ flags", but they still show up in the side pane. I'm guessing that the other flags are not being passed to clang or whatever is responsible for parsing code for the gui...
Any ideas?
Update:
The warnings have mostly disappeared, but I'm not sure why. And every time I think they're gone, I get a few again. I suspect that forcing a build of every project in the workspace has some effect, but I'm really at a loss.
In any case, modifying "other c++ flags" does seem to affect the GUI warnings, contrary to my assumption when I asked this question. But it takes time. Ahh, Xcode.
Use a pragma instead of a command line switch, as described in the answer to "Is there a way to suppress warnings in Xcode?"