Since upgrading to Xcode 5.1 this morning, a C++ library I have included in my project is failing to build due to unused const.
I have Treat Warnings as Errors: NO & Pedantic Warnings: NO
Any ideas?
Edit after request for line!:
const int NPT_SSDP_MAX_LINE_SIZE = 2048;
full warning is:
Shell script Invocation Error
Unused variable 'NPT_SSDP_MAX_LINE_SIZE'
In my case, the -Werror flag was set in Build Settings, Other Warning Flags. I just removed -Werror.
Do you have any warning about "Validate Project Settings" in your project?. Similar error went away after update to recommended settings and compile again.
In my case this error was caused by a sub-project within the main project having "Treat warnings as errors" set to YES.
To fix:
Go to build settings for your main project or sub-project (search for .xcodeproj to find all subprojects)
type in warnings into search box
Set "treat warnings as errors" to NO
This fixed my issue for xCode 5.1
Related
I installed a clangd plugin in VSCode to develop C++.
This plugin works well, but it shows some code error/waring in our project because we use a deprecated function in <zstd.h>.
include <zstd.h>
deprecated function
How can I mask this error without changing the code?
For example, I can ignore some warning in the VSCode's cpplint plugin by modifying .vscode/settings.json:
ignore some error on cpplint plugin
Can I do something like that to the VSCode's clangd plugin? thanks~
I try to use clang diagnostic, but it seems not work.
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wdeprecated-attributes"
#include <zstd.h>
#pragma clang diagnostic pop
clang diagnostic don't work
First, note that the reason for the error is not the function being deprecated, it's a parsing error ("an attribute list cannot appear here"). The note related to deprecation is just a comment that shows up in the hover, unrelated to the error diagnostic.
If you'd like to suppress the error, you can do it using https://clangd.llvm.org/config.html#suppress. For example, you could create a .clangd file in your project root containing:
Diagnostics:
Suppress: attributes_not_allowed
(Note, attributes_not_allowed is the diagnostic code of the error from the first screenshot.)
However, suppressing the diagnostic is likely to just paper over an underlying problem that's likely related to your project's configuration. A better approach would be to fix the underlying issue. To do that, please review the project setup instructions and ensure your project has a compile_commands.json and clangd is finding it; if that doesn't resolve the issue, feel free to post clangd logs for further diagnosis.
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)
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.
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.
Is there a compiler option in VS 2008 (C++) to expose uninitialized variables? I'm trying to debug a problem where the "release" build of a DLL does not work but the "debug" build of the DLL does work.
iirc, setting warning level to 4 will help with this
cl.exe sample.cpp /analyze
here's the link on MSDN
You're looking for warning number C6001
My normal debug builds seem to have this warning enabled:
warning C4700: uninitialized local variable 'xxx' used
and the warning is not present in a release build.
I don't know if this is still relevant but I was just looking for the same thing and found a solution.
You can manually change the warning-level for single warnings. In your case you have to set the level for this particular warning at least as low as your configured level of default-warnings (usually 1 or 2).
Within the project-settings within the C/C++ settings enter a manual command-line switch:
/wYxxxx
with Y being the warninglevel (e.g. 1)
and xxxx being the warningnumber in this case you should enter
/w14701
Cheers