I am using clang-tidy as a "linter" tool in development. I started to integrate 3rd party software into my code and when I include their header files using:
-I/path/to/include
tons of errors are generated, I haven't even #include the headers yet.
error: too many errors emitted, stopping now [clang-diagnostic-error]
...
/path/to/include/wchar.h:81:1: error: unknown type name 'wint_t' [clang-diagnostic-error]
wint_t fgetwc(FILE *__stream);
^
/path/to/include/wchar.h:81:15: error: unknown type name 'FILE' [clang-diagnostic-error]
wint_t fgetwc(FILE *__stream);
^
...
I compile my program using:
/usr/bin/clang-tidy-4.0 /path/to/main.cpp -checks=-*,cppcoreguidelines* -- -lang-c++ -I/path/to/include -std=gnu++11 -Wall -Werror -O0 -g -D<define variables>
It seems that these "clang-diagnostic-errors" do not stop compilation, as it continues to compile and runs fine. Is there a flag to turn this error off/suppress it? I do not want to see it since I did not write these header files.
If I get rid of the argument -I/path/to/include everything compiles fine with no errors.
There is no way to ignore clang-diagnostic-error since it's basically a compiler error.
For clang-tidy to work the analyzed code needs to be compile-able by the clang backend to generate an AST(Abstract syntax tree).
The problem is you are including headers that cannot be compiled by clang (I'm guessing windows headers intended for MSVC).
I'm not sure if this would not break something later, so just at your own risk. I managed to "solve" this (because it was just a matter of having an error on the Problems list) on VSCode:
"C_Cpp.codeAnalysis.clangTidy.args": [
"--extra-arg=-ferror-limit=1"
]
This makes clang-tidy tell the compiler to throw just one error and give up. So clang-tidy will parse whatever is left.
I know was for VSCode, but the argument can be used in other IDEs.
Related
Something is very wrong with strings. I have been using them for weeks without issue, but halfway through Monday, I started having strange issues:
[Clang IntelliSense] Error: variable has incomplete type 'std::string'
whenever I try to make a string. similar errors occur when I try wstring and ostringstream, but not stringstream. initializing std::string* s also works fine but s->append(...) results in"member has access into incomplete type 'std::string'"
This all came about because visual studio (VS) was all of a sudden unable to find some #includes that I have had for weeks, including some standard libraries (don't remember which because...). I solved that by having VS search for the correct files and it found some files (unsure if they're the same as before or different) so it no longer has an issue with the #include statements but now I have this issue.
I had been using <string.h> fine for weeks. while researching this issue, I read that <string.h> is the wrong file to use so I've tried #include <string> but there is no difference. I've since tried <strings.h> and <cstring> but no difference there either.
I checked out my external dependencies and string.h has dozens of errors, which I thought is weird because it's a standard file that I haven't touched.
I'm using VS2015, GNU make, and I see Clang IntelliSense but I also see some g++ here so I'm not sure what compiler it's actually using. also using visualGDB 5.3. let me know if I forgot anything.
#include <iostream>
#include <string>
#include <sstream>
int main(int argc, char *argv[])
{
std::string message = "uncomment";
...
message
is the part that is highlighted as having an issue (incomplete type)
std::wstring wideMessage;
also incomplete type
expected results: no problems like the past few weeks. I was able to declare, initialize, append(), whatever
actual results: can't compile/debug
errors: variable has incomplete type 'std::string' variable has incomplete type 'std::wstring' no matching constructor for initialization of 'std::ostringstream'
I see many similar issues here, but all the issues have to do with forward declaration and I don't see what that has to do with this. I'm not having any issues with classes, structs, or functions; even declaring a variable in main() is problematic
edit: based on this answer, it is likely using VC++ 14.0 as a compiler but I do not know how to tell for sure
edit 2: error message:
1> VisualGDB: Sending 45 updated source files to build machine...
1> VisualGDB: Run "make CONFIG=Debug" in directory "/tmp/VisualGDB/c/Users/pthien/VS/Whatever/Whatever" on pthien#buildserver (SSH)
1> /opt/poky/1.8/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ -march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8 --sysroot=/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi -ggdb -ffunction-sections -O0 -std=c++11 -march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8 --sysroot=/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi -ggdb -ffunction-sections -O0 -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/include -I/opt/googletest-master/googletest/include -I/opt/boost_1_61_0 -I../../cereal/cereal-1.2.2/cereal-1.2.2/include -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/websocketpp-master -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/include/websocketpp -I/opt/curl-7.54.0 -I/opt/boost_1_61_0/boost -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/include/easywsclient-master -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/include/uWebSockets-master -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/include/c++/4.9.2/experimental -I/opt/boost_1_61_0/boost/tr1/tr1 -I/opt/boost_1_61_0/tools/build/src/engine -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/include/c++/4.9.2 -I/opt/curl-7.54.0/include -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/include/cereal -I/opt/poky/1.8/sysroots/x86_64-pokysdk-linux/usr/lib/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/include-fixed -I/opt/boost_1_61_0/boost/compatibility/cpp_c_headers -I"../../../../../Program -IFiles -I(x86)/Microsoft -IVisual -IStudio -I10.0/VC/crt/src" -I"../../../../../Program -IFiles -I(x86)/Microsoft -IVisual -IStudio -I14.0/VC/include" -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/include/c++/4.9.2/arm-poky-linux-gnueabi -DDEBUG -c Whatever.cpp -o Debug/Whatever.o -MD -MF Debug/Whatever.dep
1> C:\Users\pthien\AppData\Local\VisualGDB\RemoteSourceCache\buildserver\0008\include\wchar.h(459,20): note : 'wcstold'
1> extern long double wcstold (const wchar_t *__restrict __nptr,
1> ^
1> Whatever.cpp: In function 'int main(int, char**)':
1>C:\Users\pthien\VS\Whatever\Whatever\Whatever.cpp(138,47): error : 'strlen' was not declared in this scope
1> size_t request_len = strlen(webSocketRequest);
1> ^
1> Makefile:160: recipe for target 'Debug/Whatever.o' failed
1> make: *** [Debug/Whatever.o] Error 1
1> -------------------------------------------------------------
1> Command exited with code 2
1> Executable: make
1> Arguments: CONFIG=Debug
1> Directory: /tmp/VisualGDB/c/Users/pthien/VS/Whatever/Whatever
1>VisualGDB : error : Command-line action failed
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.MakeFile.Targets(37,5): error MSB3073: The command ""C:\Program Files (x86)\Sysprogs\VisualGDB\\VisualGDB.exe" /build "C:\Users\pthien\VS\Whatever\Whatever\Whatever.vcxproj" "/solution:C:\Users\pthien\VS\Whatever\Whatever.sln" "/config:Debug" "/platform:Win32"" exited with code 1.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
This is about 10% of the output, including the beginning and the end. What's weird is the issue with strlen(). It is not underlined in the IDE, so I had no idea there was an issue with it. It makes sense because I commented out the #include for <string.h>and <cstring> and strlen() is in one of those.
If you copied your code exactly from what you have, I see two declarations of argc in your definition of main. Your compiler should definitely be throwing errors about that. Perhaps your compiler delays the read error until you declare a std::string in main? (I've had a compiler throw an error several lines after the actual error for something seemingly unrelated.) So, you may have fixed the error in having a bad file path, but perhaps your bad definition of main throws your compiler off.
Now, if that didn't work, you mentioned seeing a bunch of compilers being used. If you see a particular compiler throwing that error, then you might want to separately update said compiler. The functionality of compilers is modular, so you can pick and choose which compiler you use for which step of the compilation. VS is probably doing this to get what it figures is the best result. Sometimes compilers carry with them the files they want to use, thus updating (or even un/reinstalling) the compiler should fix the files that it carries with it. (Windows likes to do everything for you, so you might actually mess something up if you try to update the parts separately. That was always my experience, anyway. But, I haven't used Windows in well over a year, so that may have changed.)
If that still doesn't fix it, you may have to un/reinstall VS. I will admit to knowing nothing about VS, as I use Emacs to edit and Makefile/g++ to compile. My guess, however, is VS may carry all the compilers and files it needs with it, so an update or un/reinstall will (hopefully) fix your issue.
managed to avoid this issue, but probably not solve the still-unknown underlying issue, by removing an unused library from my list of directories and then reloading all directories. I'm not convinced anything was solved because reloading directories gives random results. sometimes it fixes issues and sometimes it causes new ones. Just yesterday, I reloaded and it was then unable to find system.h and time.h (don't remember the names). I was troubleshooting that but the issue disappeared a few hours later. anyway
I posted a follow-up question here
I am on Ubuntu 16.04, GCC 5.4.
According to here one can disable warnings from external headers by treating them as system headers. However, when I am using VTK I came across a warning that I am unable to disable. Below is the minimum code to reproduce it
#include "vtkVersion.h"
int main(){
return 0;
}
Compile it with g++ main.cpp -isystem /usr/include/vtk-5.10/ return warning message
In file included from /usr/include/c++/5/backward/strstream:50:0,
from /usr/include/vtk-5.10/vtkIOStream.h:108,
from /usr/include/vtk-5.10/vtkSystemIncludes.h:40,
from /usr/include/vtk-5.10/vtkIndent.h:24,
from /usr/include/vtk-5.10/vtkObjectBase.h:43,
from /usr/include/vtk-5.10/vtkObject.h:41,
from /usr/include/vtk-5.10/vtkVersion.h:29,
from Example.cpp:3:
/usr/include/c++/5/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. [-Wcpp]
#warning \
^
If VTK is not installed you can simply install it with sudo apt-get install libvtk5-dev
Why does the warnings appeared? In my code I have very strict compiler flags and I treat warnings as errors. However, not all external libraries are coded with such strict compiler flags, I am able to get away with including the external headers with the -isystem flag but VTK is giving me problems. My ugly workaround is adding -Wno-deprecated in my own compiler flags to get pass it but obviously this is not the right way to do it. What's the best way to solve this?
I'm trying to get emscripten to work on OS X 10.8, see this post for some related issues there. Apparently the clang++ version shipped with Xcode is too old, so I got a recent clang 3.7.0 using MacPorts. I even told CMake to use that compiler (passing -DCMAKE_CXX_COMPILER=clang++-mp-3.7 on the command line), but it still fails:
[ 33%] Building CXX object CMakeFiles/optimizer.dir/parser.cpp.o
/opt/local/bin/clang++-mp-3.7 -std=c++11 -fno-exceptions -fno-rtti -O3 -DNDEBUG
-o CMakeFiles/optimizer.dir/parser.cpp.o
-c …/emsdk/emscripten/master/tools/optimizer/parser.cpp
In file included from …/emsdk/emscripten/master/tools/optimizer/parser.cpp:2:
In file included from …/emsdk/emscripten/master/tools/optimizer/parser.h:12:
…/emsdk/emscripten/master/tools/optimizer/istring.h:3:10: fatal error:
'unordered_set' file not found
#include <unordered_set>
^
1 error generated.
I can reproduce that issue by launching the compiler from the command line. In parallel build mode, sometimes it's instead complaining about <cstdint> for optimizer.cpp instead. Both these headers exist in /opt/local/libexec/llvm-3.7/include/c++/v1/.
What's the canonical way to use the macports-installed version of clang++ including its headers? Do I have to use -I and work out the full path, or is there something shorter?
Can I safely do so without also switching the runtime library to the one shipped with MacPorts' clang? If not, can I somehow encode the full path of the runtime library into the created binary, either for that single library or using the -rpath argument to ld or some equivalent alternative?
Update: I get unresolved symbols when I try to link stuff after specifying the include directory manually, and I don't know how to solve that. The libcxx package from MacPorts is empty except for a readme file.
I've solved the original problem by adding CXXFLAGS=--stdlib=libc++ to the environment. Then even the system version of clang will do everything I need. That flag works magic for MacPorts' version of clang as well: specifying that I get a successful build, and I can even verify (using the -E compiler switch) that it's using the headers I mentioned before. I'm still not certain whether there is anything to ensure that the headers match the system's version of libc++, though.
I'm on Ubuntu 13.04 32 platform. I'm trying to compile awn with latest vala. I get following error message.
vala-utils.cc: In function 'void awn::vala_array_destroy(gpointer, gint, GDestroyNotify)':
vala-utils.cc:358:6: error: no previous declaration for 'void awn::vala_array_destroy(gpointer, gint, GDestroyNotify)' [-Werror=missing-declarations]
cc1plus: some warnings being treated as errors
How can I fix that error?
At the top of vala-utils.cc insert the function prototype:
void vala_array_destroy(gpointer array, gint array_length, GDestroyNotify destroy_func);
This will silence the warning which is causing the build to fail due to -Werror defined in the Makefile. Consider raising a pull request for the benefit of the maintainers.
Alternatively modify ln.89 in configure.ac and remove the -Werror to stop the warning failing the build.
This actually a warning, and a rather pedantic one at that.
It's saying that the global function awn::vala_array_destroy has not been declared beforehand. Usually this is a sign of a programmer's mistake, but from the source it seems to me that:
this function is only supposed to be used by awn::vala_array_free directly below it (in which case it should really have been given internal linkage), or
a declaration is available in some header elsewhere (in which case it's probably in the wrong header, as it ought to be in vala-utils.h).
The long and short of it is that the code is probably fine, if a little strangely designed. This case is being treated as an error because you have -Werror turned on for this warning, turning it into an error.
I don't know how you're building the library, but you could adjust the compiler flags to avoid this; by default, GCC does not emit this warning, nor turn it into an error. Alternatively, you could add the function declaration into vala-utils.h yourself. You should also take up the issue with the library's maintainers.
Update: I found the culprit on line 89 of AWN's configure.ac. You should definitely take this up with the library maintainers. I'd be amazed if this had not already been reported as a bug; I believe it was introduced in this revision.
I downloaded zthreads (found here: http://zthread.sourceforge.net/) and tried to compile but I get this error from make:
MutexImpl.h:156: error: there are no arguments to 'ownerAcquired' that depend on a template parameter, so a declaration of 'ownerAcquired' must be available
MutexImpl.h:156: error: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)
and then after that for every function in that source file I get this kind of error:
MutexImpl.h:167: error: there are no arguments to 'function' that depend on a template parameter, so a declaration of 'function' must be available
So I'm guessing it's a makefile error but I'm not for sure how to tell make to tell g++ to compile the files with -fpermissive. Does anyone know how to put that into the makefile (if that is the problem)?
CXXFLAGS += -fpermissive
Standard gmake convention is to use the CXXFLAGS variable to pass options to the C++ compiler. You can take advantage of that fact as well as a feature called "command-line overrides" to get your extra flag tacked onto the flags passed to g++ by invoking gmake this way:
make CXXFLAGS+=-fpermissive
I downloaded the source myself to verify that this works and found that it does, although there are still a bunch of other warnings emitted. You may wish to log a bug for these issues if you intend to continue using the library.
Hope this helps,
Eric Melski
I got rid of all these errors changing the code: for each line with that mistake, add this-> to the function that provokes the error. In the line you quote:
ownerAcquired must be changed by this->ownerAcquired
I hope this helps