RFR: JDK-8148629: Disable remaining warnings in awt/fontmanager

[Coleen Phillimore]

On 2/5/16 7:12 AM, Magnus Ihse Bursie wrote:
> On 2016-02-05 10:41, Erik Joelsson wrote:
>> Magnus pointed out that I mistakenly replaced fno-strict-aliasing 
>> with -Wno-strict-aliasing. Reverted that change.
>>
>> http://cr.openjdk.java.net/~erikj/8148629/webrev.jdk.02/
> The new webrev looks good to me.
>
> However, the use of -w for individual files is a bit scary. :-( It's 
> not easy to grep for (like "WARNINGS_AS_ERRORS") and it's quite broad. 
> Please make sure you update JDK-8079958 and JDK-8079955 with clear 
> instructions on what have been disabled for these libraries, and how 
> to fix this, so this does not get lost.
>
> I believe this is the last instance where we had warnings in native 
> compilation printed during every build, so when this is pushed I think 
> it's time for a small celebration. :-)

Yes, I think there should be a party!

I don't understand modern makefiles but I think this is really good and 
better to turn off certain files with -w than all of them.  It looks 
like you turned on warning-as-errors so if awt has new warnings in 
different files, they can fix them.   That seems good.

Thanks!!
Coleen
>
> /Magnus
>
>>
>> /Erik
>>
>> On 2016-02-05 10:05, Erik Joelsson wrote:
>>> A while back, Magnus did a tremendous job of disabling most warnings 
>>> in the JDK native libraries and enabling warnings as errors on most 
>>> of them. However, some libraries, typically awt related, proved to 
>>> be harder.
>>>
>>> One of the reasons was that some toolchains had different warning 
>>> labels specified for C vs C++ and would not accept the other kind 
>>> without printing new warning. For libraries containing both C and 
>>> C++ source files, this prevented us from disabling all warnings. 
>>> This limitation in SetupNativeCompilation has since been fixed so I 
>>> could use that functionality to disable most remaining warnings.
>>>
>>> Another reason is that some source files contain warnings that are 
>>> deemed severe enough by the compiler that they can't be individually 
>>> ignored. Since the team owning that source seem unwilling to fix 
>>> these warnings anyway, I have simply disabled all warnings on those 
>>> specific files, for the specific toolchains where it applies. I have 
>>> tried to add descriptive comments explaining each such occurrence.
>>>
>>> I have tested this by building a full hotspot job and an openjdk 
>>> only job in JPRT. It is possible that people building with other 
>>> toolchain versions than Oracle will start seeing new build failures 
>>> because of more warnings in these libraries. In that case, either 
>>> --disable-warnings-as-errors, submit fixes for the warnings, or add 
>>> more warning ignores.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8148629
>>> Webrev: http://cr.openjdk.java.net/~erikj/8148629/webrev.jdk.01/
>>>
>>> /Erik
>>
>