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):
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:
AstNodePtrcond=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
--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.
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::parseClangAstDump
is 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.cpp
under 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.
aha.. the
split
function 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
IfStmt
with 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
--clang
there is no false positive:Since
_instances
is definedstatic
the message about returning a local variable should be wrong, correct?When
clang
orclang++
can not be found in the path the file with thestderr
output 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