Several times a day the Chromium code base is built with Microsoft VC++'s /analyze compile option. This does static code analysis which has found numerous bugs (see https://crbug.com/427616). While it is possible to visit the /analyze builder page and look at the raw results (https://build.chromium.org/p/chromium.fyi/builders/Chromium%20Windows%20Analyze) this works very poorly.
As of this writing there are 2,702 unique warnings. Some of these are in header files and fire multiple times so there are a total of 11,202 warning lines. Most of these have been examined and found to be false positives. Therefore, in order to sanely examine the /analyze warnings it is necessary to summarize the warnings, and find what is new.
There are scripts to do this.
The necessary scripts, which currently run on Windows only, are checked in to tools\win\new_analyze_warnings. Typical usage is like this:
> set ANALYZE_REPO=d:\src\analyze_chromium > retrieve_latest_warnings.bat
The batch file using the associated Python scripts to retrieve the latest results from the web page, create a summary file, and if previous results were found create a new warnings file. Typical results look like this:
analyze0067_full.txt analyze0067_summary.txt analyze0067_new.txt
If ANALYZE_REPO is set then the batch file goes to %ANALYZE_REPO%\src, does a git pull, then does a checkout of the revision that corresponds to the latest warnings, and then does a gclient sync. The warnings can then be easily correlated to the specific source that triggered them.
The new.txt file lists new warnings, and fixed warnings. Usually it can accurately identify them but sometimes all it can say is that the number of instances of a particularly warning has changed, which is usually not of interest. If you look at new warnings every day or two then the number of new warnings is usually low enough to be quite manageable.
The summary.txt file groups warnings by type, and then sorts the groups by frequency. Low frequency warnings are more likely to be real bugs, so focus on those. However, all of the low-frequency have been investigated so at this time they are unlikely to be real bugs.
The majority of new warnings are variable shadowing warnings. Until -Wshadow is enabled for gcc/clang builds these warnings will continue to appear, and unless they are actually buggy or are particularly confusing it is usually not worth fixing them. One exception would be if you are planning to enable -Wshadow in which case using the list or relevant shadowing warnings would be ideal.
Some of the warnings say that out-of-range memory accesses will occur, which is pretty scary. For instance “warning C6201: Index ‘-1’ is out of valid index range ‘0’ to ‘4’”. In most cases these are false positives so use your own judgment when deciding whether to fix them.
The full.txt file contains the raw output and should usually be ignored.
If you have any questions then post to the chromium dev mailing list.