@gyorb Actually, I think it was working but I misread the results, in the CodeChecker UI. The bugs in the skiped files are there but "resolved". It there any way to remove permanently all revolved bugs? There are not useful to me since they appeared before I set my analysis to skip them.
I've updated version of thrift in the requirements from 0.9.1 to 0.11.0 and everything seems to generate nicely
server is coming up, storing now works, but firefox says: TypeError: Thrift.copyList is not a function (report_server_types.js:2068:27)
server is coming up, storing now works, but firefox says: TypeError: Thrift.copyList is not a function (report_server_types.js:2068:27)
Any ideas on that?
let us know if you have any other questions
When compiling my project with clang++ on linux I always use the flag -stdlib=libc++ (selecting another std library). And a different std as well (-std=c++17). But when I check the static analyzer command I see that the libstdc++ headers are added to the compile line instead of the ones from libc++.
I already tried to set the commandline option --saargs to a file containing: -stdlib=libc++ and -std=c++17 but that didn't change anything.
What is the correct way to select a standard library?
hi, the -std=c++17 should not cause a problem, my first idea is that during the detection of the implicit includes for the compiler in https://github.com/Ericsson/codechecker/blob/046409b65457a5a0cab239f9d6d1df4906122d73/analyzer/codechecker_analyzer/buildlog/log_parser.py#L315 we do not forward the -stdlib=libc++ flag if it is in the compile command and without it the libstdc++ headers are collected, the saargs arguments are only forwarded for the actual analysis call
could you send an example of the compile command which is logged and the analysis command created from it?
I used the following CodeChecker command:
CodeChecker check --logfile compile_commands.json --output ../results --verbose debug --capture-analysis-output
I've made a PR Ericsson/codechecker#2294 with some changes, where the -stdlib= is kept where the implicit include paths are detected, with that it should return the right include paths, could you check it?
After applying the patch I got a python error: https://gist.github.com/matthijs/dd74249b585e00abdef17f7ecfd3af11
hm that also happens on current master without this patch
But unfortunately that gives another problem with the order of the includes, the order is now:
-isystem /usr/lib/llvm-7/lib/clang/7.0.1/include -isystem /usr/lib/llvm-7/include/c++/v1 -isystem /usr/local/include -isystem /usr/include/x86_64-linux-gnu -isystem /usr/include
but the include /usr/lib/llvm-7/include/c++/v1 should come before /usr/lib/llvm-7/lib/clang/7.0.1/include
it is now causing a failure described in a debian bug report here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855222
you use the clang from a standard debian package or you built it from source?
do you use the same clang for compilation and analysis?
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/llvm-7/bin/../include/c++/v1
/usr/include/clang/7.0.1/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
yes, this is the debian package from buster and I use the same clang for compilation and analysis.
we are reviewing how the compiler include paths are handled, there are multiple PR which introduce some changes Ericsson/codechecker#2297, Ericsson/codechecker#2294, Ericsson/codechecker#2272 (there is still some discussion how this change will affect the include paths and what should be the default behaviour) probably all of them will be needed to fix the problem
Is there already an ETA for the next release?