I dont see all my code in the ‘Code’ tab (in sonar.sources)
I see code I dont want to see in ‘Code’ tab (Java stuff, in sonar.exclusions)
Looks like sonar-scanner fails to parse some (a lot of) files - ERROR: Unable to parse file: /home/user/Development/Company/server/lib/server/allocator/TreeNavigator.cpp
java.lang.IllegalStateException: Several good alternatives: AMBIGUOUS @7e4b7dbe line:209
I get a lot of warnings, not sure it affects analysis quality - WARN: Unknown language standard “gnu++1z”, will use “c++17” from “sonar.cpp.std” for file /home/user/Development/Company/server/lib/server/backup/LbnCoder.cpp
The command line as following
sonar-scanner
-Dsonar.exclusions=ext//*,Buggsbunny//,gui/**/,cmake-build-debug//*,java-common//,mgmt/**/,bugsbunny-apis/**/*
-Dsonar.sources=server,utils,proc
-Dsonar.language=cpp
-Dsonar.cpp.std=c++17
-Dsonar.cfamily.build-wrapper-output=bw-output \
EDIT001: Ok, looks like I solved the exclusion problem, however, the number CLOC reported looks too low, I suspect that part of files is skipped. In addition, where are include files which may have considerable amount of code, for example templates.
For your point 4, it means that the code will be analyzed as if it was written in another version of C++ than the one you are using in your build system. As you can see in https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html, gnu++1z is identical to gnu++17, which is roughly C++17 + gcc-specific extensions. If your codebase does not make too much use of those extensions, your analysis should not be too much broken.
For your point 3, could you create a small example that reproduces this error? Or alternatively send us the full logs as well as the content of the TreeNavigator.cpp file?
For your point 1, it’s hard to say anything without more details. What files are missing?
How I can share with you the log/code without exposing it publicly?
as for points 2,3 and EDIT001 looks like I solved the problem, header files were omited since by default “c++” does not include “.h” files
I was thinking this when I started with SonarQube but it turned out to be a more complicated measure than I expected. using the C / C++ build-wrapper it is only code used in the compilation that will get counted. Anything in unused functions, behind untrue #ifdef and so on will all be excluded. Then I think it does not count whitespace, comments, includes, etc. Once I had accounted for all that I think the cloc was about correct for me.
I would suggest you start off with a simple setup then improve it iteratively to get you where you want to be.
Drop your exclusions lines to start with. It might take a scanner a little longer to complete but unless these are huge areas of code I expect the extra time will be hard to notice. -Dsonar.exclusions=ext/ **/*,Buggsbunny/** / *,gui/**/* ,cmake-build-debug/ **/*,java-common/** / *,mgmt/**/* ,bugsbunny-apis/**/*
If you are using sources to include things -Dsonar.sources=server,utils,proc then you probably will not need to also exclude files unless they are within those paths. ./server will be include and ./ext is implicitly excluded. If you want to exclude ./server/ext/ then that is going to need an exclusion of either ./server/ext/** or */ext/**. By changing one parameter at a time from a simple basic setup, you should be able to work out what is happening at each stage.
Do not include unrequired parameters. You may accidentally force the analysis to do the wrong thing.
-Dsonar.language=cpp
-Dsonar.cpp.std=c++17
If you are using a common C++ compiler I believe the build wrapper is smart enough to pick up both these settings from the compilation output. However, they should be harmless if your code base uses a single standard throughout and does not include C and C++ compilation steps but just C++.
I found it took me quite a while to work out what SonarQube is doing when I started with it. It was often not doing what I expected it to, but something that was sensible once you understood what the documentation was trying to say.
not exactly the way Sonar works… if you dont specify the standard it will default to c++ 14, we are using c++ 17. if you dont specify language it will start counting bash/xml/younameit files, from my point of view, useless noise.
I specify the standard in my gcc commands which I think the build-wrapper then reads. I can see that blocking types that SonarQube could comment on but that you wish for it not to makes sense.
There are some slight inaccuracies in the previous messages, and, since you seem to use SonarCloud the situation has also changed since your first message, so let’s recap:
A new version of the CFamily plugin has been deployed last week on SonarCloud . With this version, properties such as sonar.cpp.std which had been deprecated for a long time are now totally ignored.
The standard version detection mechanism has been updated to better handle unknown versions. You should try it again. By the way, the gnu++1z flag is either experimental (old compiler versions) or deprecated (new compiler versions), so maybe so could consider updating it in your build chain?
The standard version is read by the build wrapper from the command line of the compiler. If you don’t specify any, it will default to what your compiler uses as a default value, not to any hard-coded value.
The analysis engine is totally different between version 5.x and version 6.0 of the CFamily plugin. So hopefully the issue you used to have is no longer present. Could you try again with the new version? If it still does not work, you can send me the logs at the address I already sent privately to you.
Hm… wasnt aware that -std=c++17 is already here. In any case, this flag is added automatically by CMake, I guess I have to update the CMake to generate right gcc options.
In any case, I just re-run scanner, it downloaded new plugins, everything worked as a charm, no failures, no warnings, now my dashboard is full of bugs!
the situation has also changed since your first message, so let’s recap: