In my opinion, the clang import is very promising. It's far from complete but it's possible to test it now.
So feel free to test the "--clang" option.
If you write something like for instance:
cppcheck --clang --debug lib/settings.cpp
then the output might contain some ?UnhandledId? tokens. That will be fixed ... Let me know if you see some other kind of garbage (wrong variable names, bad operators, etc).
And Cppcheck should not crash when --clang is used.
I have used clang 7.0.1-8 during the development and I expect there are minor differences with other Clang versions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
strange. I don't know how that can happen.. if something fails then as far as I see you should see some error message on the screen. Can you see if clangimport::parseClangAstDump is called?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem is not the ast itself but the actual clang command. cppcheck --clang --debug lib/settings.cppunder Windows gives me the follwing cmd string that is passed to execudeCommand(): clang++ -cc1 -ast-dump -internal-isystem "d:\\Tools\\LLVM\\lib\\clang\\9.0.0\\include" -internal-isystem "D:\\Tools\\Microsoft -internal-isystem "C:\\Program -internal-isystem "C:\\Program -internal-isystem "C:\\Program -internal-isystem "C:\\Program -fcxx-exceptions lib/settings.cpp
looks like the -internal-isystem paths aren't completely enclosed with "". If I copy the command line and fix the " then everything works.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have not looked into the clang import, just saw that you are working on it.
What exactly should the clang import do? From what I saw until now my guess is that clang is used to create the AST instead of internal code like simplecpp.
I thought I just test it so I maybe get a better understanding of it, but it crashed. Not sure what went wrong (I used Cygwin 64 on Windows 7):
Checking./lib/analyzerinfo.cpp...[NewThread10648.0x25c8]Thread1"cppcheck"receivedsignalSIGSEGV,Segmentationfault.0x00000001004a1487in__gnu_cxx::__atomic_add(__mem=0x3b,__val=1)at/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/include/c++/ext/atomicity.h:5353{__atomic_fetch_add(__mem,__val,__ATOMIC_ACQ_REL);}(gdb)bt#0 0x00000001004a1487 in __gnu_cxx::__atomic_add (__mem=0x3b, __val=1) at /usr/lib/gcc/x86_64-pc-cygwin/7.4.0/include/c++/ext/atomicity.h:53#1 0x00000001004a154a in __gnu_cxx::__atomic_add_dispatch (__mem=0x3b, __val=1) at /usr/lib/gcc/x86_64-pc-cygwin/7.4.0/include/c++/ext/atomicity.h:96#2 0x0000000100674181 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_add_ref_copy (this=0x33) at /usr/lib/gcc/x86_64-pc-cygwin/7.4.0/include/c++/bits/shared_ptr_base.h:138#3 0x000000010066d389 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::__shared_count (this=0xffff8508, __r=...) at /usr/lib/gcc/x86_64-pc-cygwin/7.4.0/include/c++/bits/shared_ptr_base.h:691#4 0x000000010066a916 in std::__shared_ptr<clangimport::AstNode, (__gnu_cxx::_Lock_policy)2>::__shared_ptr (this=0xffff8500) at /usr/lib/gcc/x86_64-pc-cygwin/7.4.0/include/c++/bits/shared_ptr_base.h:1121#5 0x000000010065dc70 in std::shared_ptr<clangimport::AstNode>::shared_ptr (this=0xffff8500) at /usr/lib/gcc/x86_64-pc-cygwin/7.4.0/include/c++/bits/shared_ptr.h:119#6 0x00000001004a6c39 in clangimport::AstNode::createTokens (this=0x800fbdac0, tokenList=0xffffadb0) at lib/clangimport.cpp:765#7 0x00000001004a4837 in clangimport::AstNode::createTokens (this=0x801797c50, tokenList=0xffffadb0) at lib/clangimport.cpp:570#8 0x00000001004aaab2 in clangimport::AstNode::createTokensFunctionDecl (this=0x8012f85e0, tokenList=0xffffadb0) at lib/clangimport.cpp:1014#9 0x00000001004a692f in clangimport::AstNode::createTokens (this=0x8012f85e0, tokenList=0xffffadb0) at lib/clangimport.cpp:744#10 0x00000001005ebb5c in clangimport::AstNode::createTokens1 (this=0x8012f85e0, tokenList=0xffffadb0) at lib/clangimport.cpp:237#11 0x00000001004ac17c in clangimport::parseClangAstDump (tokenizer=0xffffadb0, f=...) at lib/clangimport.cpp:1165#12 0x00000001004b0892 in CppCheck::check (this=0xffffbce0, path=...) at lib/cppcheck.cpp:339#13 0x00000001005d1f6e in CppCheckExecutor::check_internal (this=0xffffc8e0, cppcheck=..., argv=0xffffcbb0) at cli/cppcheckexecutor.cpp:913#14 0x00000001005d0b80 in CppCheckExecutor::check (this=0xffffc8e0, argc=5, argv=0xffffcbb0) at cli/cppcheckexecutor.cpp:227#15 0x00000001005d3f2b in main (argc=5, argv=0xffffcbb0) at cli/main.cpp:95
I have not looked into the clang import, just saw that you are working on it.
What exactly should the clang import do? From what I saw until now my guess is that clang is used to create the AST instead of internal code like simplecpp.
Yes the intention is that it will be an option for users that are not satisfied with the builtin parser in Cppcheck.
My main reason for adding it was that I want that users will be able to trust our "bug hunting" feature. With limited parsing we can't detect all bugs.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
interesting. that command works for me. It crashes for you in clangimport::parseClangAstDump so if I get your ast I should be able to reproduce it.
Can you please open the file clangimport.cpp. In the function createTokens1(TokenList *tokenList) there is this code: //dumpAst();. Can you please uncomment that and rerun Cppcheck. Each AST tree that is converted is then printed on the screen. Can you show me the last AST tree before the crash?
It seems that the crash happens on this line:
AstNodePtr cond = children[children.size() - 3];
I guess you get a IfStmt with fewer than 3 children .. strange!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, here is the end of the dumpAst() output for the command ./cppcheck --clang --cppcheck-build-dir=./temp -I./externals/tinyxml ./lib/analyzerinfo.cpp, I hope I got everything that is necessary:
When clang or clang++ can not be found in the path the file with the stderr output contains something like "File/Command .. not found" (in German it contains Der Befehl "clang" ist entweder falsch geschrieben oder
konnte nicht gefunden werden..
There is no hint from Cppcheck that something went completely wrong.
The AST (res.second) is empty.
Nothing is checked, no messages are generated, but from Cppcheck's output it looks like everything went fine.
Last edit: versat 2020-01-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In my opinion, the clang import is very promising. It's far from complete but it's possible to test it now.
So feel free to test the "--clang" option.
If you write something like for instance:
then the output might contain some
?UnhandledId?tokens. That will be fixed ... Let me know if you see some other kind of garbage (wrong variable names, bad operators, etc).And Cppcheck should not crash when
--clangis used.I have used clang 7.0.1-8 during the development and I expect there are minor differences with other Clang versions.
Hmm for me it does nothing. It just prints
Checking lib/settings.cpp...and then nothing happens. I tried clang v7.0.1 and v9.0strange. I don't know how that can happen.. if something fails then as far as I see you should see some error message on the screen. Can you see if
clangimport::parseClangAstDumpis called?Maybe it's some dump format mismatch.. Could you show me some ast dump. Put this in a file
1.c:And then, what is the output of this comand:
The problem is not the ast itself but the actual clang command.
cppcheck --clang --debug lib/settings.cppunder Windows gives me the follwing cmd string that is passed to execudeCommand():clang++ -cc1 -ast-dump -internal-isystem "d:\\Tools\\LLVM\\lib\\clang\\9.0.0\\include" -internal-isystem "D:\\Tools\\Microsoft -internal-isystem "C:\\Program -internal-isystem "C:\\Program -internal-isystem "C:\\Program -internal-isystem "C:\\Program -fcxx-exceptions lib/settings.cpplooks like the -internal-isystem paths aren't completely enclosed with "". If I copy the command line and fix the " then everything works.
aha.. the
splitfunction has to handle"thendoes that work now?
Yes now it works for me :)
I have not looked into the clang import, just saw that you are working on it.
What exactly should the clang import do? From what I saw until now my guess is that clang is used to create the AST instead of internal code like simplecpp.
I thought I just test it so I maybe get a better understanding of it, but it crashed. Not sure what went wrong (I used Cygwin 64 on Windows 7):
Her is some GDB output for the crash:
Clang info:
It also crashes when I try to analyze ./cli (backtrace looks similar):
Last edit: versat 2020-01-23
Yes the intention is that it will be an option for users that are not satisfied with the builtin parser in Cppcheck.
My main reason for adding it was that I want that users will be able to trust our "bug hunting" feature. With limited parsing we can't detect all bugs.
interesting. that command works for me. It crashes for you in clangimport::parseClangAstDump so if I get your ast I should be able to reproduce it.
Can you please open the file clangimport.cpp. In the function
createTokens1(TokenList *tokenList)there is this code://dumpAst();. Can you please uncomment that and rerun Cppcheck. Each AST tree that is converted is then printed on the screen. Can you show me the last AST tree before the crash?It seems that the crash happens on this line:
I guess you get a
IfStmtwith fewer than 3 children .. strange!Ok, here is the end of the dumpAst() output for the command
./cppcheck --clang --cppcheck-build-dir=./temp -I./externals/tinyxml ./lib/analyzerinfo.cpp, I hope I got everything that is necessary:Last edit: versat 2020-01-23
yes that is the exact tree I wanted to have. weird AST. In your Clang AST output there are only 2 children for the IfStmt.
maybe you can try it again. I have tried to fix your segmentation fault.
I have tried it with your change and now I get this for
./cppcheck --clang --cppcheck-build-dir=./temp -I./externals/tinyxml ./lib/analyzerinfo.cpp:ok thanks.. what is the backtrace?
Somehow GDB is not able to show a backtrace for this segmentation fault:
The content of cppcheck.exe.stackdump is pretty useless.
I will try it with a debug build.
I managed to let cygwin start the GDB when a segmentation fault happens and got this output:
Last edit: versat 2020-01-24
can you try again. I have installed clang-9 and ensured that works for me. I found and fixed a few problems.
Great. It works now for me under Cygwin 64.
One thing I instantly noticed is a false positive that I get with
--clang:Without
--clangthere is no false positive:Since
_instancesis definedstaticthe message about returning a local variable should be wrong, correct?When
clangorclang++can not be found in the path the file with thestderroutput contains something like "File/Command .. not found" (in German it containsDer Befehl "clang" ist entweder falsch geschrieben oder konnte nicht gefunden werden..There is no hint from Cppcheck that something went completely wrong.
The AST (res.second) is empty.
Nothing is checked, no messages are generated, but from Cppcheck's output it looks like everything went fine.
Last edit: versat 2020-01-27