getting a handle on build warnings

[Jonathan Gibbons]

I've written a program to analyze the warnings in a build log, 
containing most of
the ideas I outlined earlier, and more.

Right now, a "warning" is defined as a line containing the string "warning"
with false positives filtered out (e.g. a reference to a file called 
warning.png)

It can generate a report in plain text or html, containing any/all of 
the following:
- comparison against a reference log, such as the log for an earlier 
promoted build
- a summary of the warnings, grouped by the location contained in the 
warning
- a summary of the warnings, grouped by the type of the warning
The summaries are given sorted both alphabetically and by frequency.

I've attached a sample of the output. The input was the log for a build 
on my
laptop. For the purposes of testing, the "reference" was the same log 
truncated
to 25000 lines.

The big surprise: One file is responsible for nearly 72% of all the 
warnings in this
build: 1928 warnings out of a total of 2684!  The file in question is
    com/sun/java/util/jar/pack/coding.cpp

The corollary is good news for everyone else; there are fewer warnings 
through
the rest of the build than I expected, with only 14 files having 10 or 
more warnings.
But, there are still over 150 files containing warnings :-(

-- Jon



Jonathan Gibbons wrote:
> Well, here's an unexpected initial result.
>
> I just ran a build of langtools+jdk on my ubuntu laptop.   I got a 
> whopping 2658 warnings!!  [Those who volunteered to help get rid of 
> all the warnings, don't all step back at once!]  But surprisingly, 
> after a quick "sort -u", only 625 of them are unique. So that means we 
> get on average a 4x bang for the buck for each warning we fix :-)
>
> -- Jon
>
>
> On Jul 11, 2008, at 11:02 AM, Jonathan Gibbons wrote:
>
>> Depending on what lint options you use, deprecation warnings are 
>> typically reported as a single "Note:" at the end of the compilation, 
>> rather than as individual warning messages.  Ideally, they should go 
>> too, but for now, I'd settle for removing messages that show up as 
>> diagnostics in IDEs, emacs, etc.
>>
>> For my part, I work mostly in the langtools area,  and we are having 
>> a general background effort to clean up the code there. The goal is 
>> to clean the code and then use -Werror to treat any reappearance of 
>> warnings as errors.
>>
>> -- Jon
>>
>>
>> On Jul 11, 2008, at 10:52 AM, Rob Ross wrote:
>>
>>> Just curious, would part of this revision process entail removing 
>>> calls to deprecated methods and replacing them with their documented 
>>> replacement methods?
>>>
>>> There are many warnings about calls to deprecated methods in the 
>>> OpenJDK code.
>>>
>>>
>>> Rob Ross, Lead Software Engineer
>>> E! Networks
>>>
>>> ---------------------------------------------------
>>> "Beware of he who would deny you access to information, for in his 
>>> heart he dreams himself your master." -- Commissioner Pravin Lal
>>>
>>>
>>>
>>> On Jul 11, 2008, at 10:43 AM, Jonathan Gibbons wrote:
>>>
>>>>
>>>> On Jul 11, 2008, at 10:00 AM, Thorbjørn Ravn Andersen wrote:
>>>>
>>>>> Jonathan Gibbons skrev  den 11-07-2008 13:52:
>>>>>>
>>>>>> Yes, that technique can work well. But either way, the next step is
>>>>>> to try writing the code to analyze the build log, to see how far 
>>>>>> the general
>>>>>> idea can be taken, and how much interest there is to track/fix 
>>>>>> warnings.
>>>>>>
>>>>> Personally I'd like there to be no warnings at all, and would like 
>>>>> to contribute work to get there
>>>>>
>>>>
>>>> Thank you.
>>>>
>>>> Getting rid of the actual warnings will require cooperation from 
>>>> the teams who are
>>>> responsible for the various parts of the code. In some cases, there 
>>>> may be resistance,
>>>> since stability is sometimes preferred over "no warnings".  That 
>>>> being said, what I'm
>>>> hoping to achieve with this discussion and any related effort is a 
>>>> non-intrusive way
>>>> of gathering information about warnings, so that we have a better 
>>>> understanding of
>>>> where the warnings are, in what areas of the code and in which 
>>>> source files.  That way,
>>>> we can work with the teams involved to see if there is interest in 
>>>> reducing their
>>>> warning count in as safe a way as possible.  Any assistance in 
>>>> getting to that point
>>>> would be welcome.
>>>>
>>>> (Note that anyone contributing to OpenJDK must first sign the Sun 
>>>> Contributor Agreement;
>>>> you can find details at http://sca.dev.java.net.)
>>>>
>>>> -- Jon
>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20080713/e5eb68aa/report.html>