RFR: JDK-8074859 Turn on warnings as error

[Magnus Ihse Bursie]

On 2015-04-20 09:02, Erik Joelsson wrote:
> Looks good to me.
Thanks Erik.

Unfortunately, I never got round to pushing this. In the meantime, the 
codebase evolved, and I had to add a couple of more disabled warnings. I 
also modified the help text on a failed build slightly.

Here's the updated webrev: 
http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors/webrev.01

/Magnus


>
> /Erik
>
> On 2015-04-17 14:52, Magnus Ihse Bursie wrote:
>> With JDK-8074096, the number of warnings in the product was reduced 
>> to a minimum. This enables the next step, which is turning on the 
>> respective compiler flags that turns warnings into errors. In the 
>> long run, this is the only way to keep the warnings from creeping back.
>>
>> Even with JDK-8074096, the product does not build 100% warning free. 
>> This is due to some warnings that cannot be disabled, or (in one 
>> case) where C and C++ code is mixed, and warnings for both languages 
>> cannot be used. A system similar to the one introduced in JDK-8074096 
>> is therefore needed, in which individual libraries can be exempted 
>> from this flag, until such warnings are fixed. A library can thus 
>> disable warnings as errors with WARNINGS_AS_ERRORS := false, or 
>> (better) use a toolchain-specific version, e.g WARNINGS_AS_ERRORS_gcc 
>> := false. This is intended as a temporary measure, though. The 
>> long-term solution is reasonably to fix the warnings and remove that 
>> argument.
>>
>> Also, different versions of compilers can generate a different set of 
>> warnings. It is therefore necessary to be able to turn off this 
>> globally. Therefor a new flag for configure is introduced: 
>> --disable-warnings-as-errors.
>>
>> While the code compiles without errors on the build systems used 
>> internally at Oracle, this might not be the case on other 
>> combinations of operating system versions and toolchain versions. To 
>> facilitate for unexpecting developers, a help message is added if the 
>> build fails, that suggests using --disable-warnings-as-errors. This 
>> solution was chosen as a compromise between the "hard core" solution 
>> of turning on warnings as errors by default for anyone, and the 
>> cowar... erm, conservative solution of checking if the compiler 
>> versions exactly match what's used inside Oracle (and therefore 
>> regularly tested), and only turn it on in that case.
>>
>> Similarly to JDK-8074096, I intend to file follow-up bugs for each 
>> individual library that got a WARNINGS_AS_ERRORS_* := false.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074859
>> WebRev for top: 
>> http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors-top/webrev.01
>> WebRev for jdk: 
>> http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors-jdk/webrev.01
>>
>> Some comments:
>>
>> * I needed to add a few more DISABLED_WARNINGS. For windows, this is 
>> most likely due to the recent compiler change. For other libraries, 
>> I'm not sure, but it might well be the result of recent changes that 
>> has introduced new warnings. If so, it highlights the need of this 
>> patch to keep the build warning free.
>>
>> * For a few libraries and toolchains, there is *both* 
>> WARNINGS_AS_ERRORS := false and a DISABLED_WARNINGS list. This is the 
>> case if not all warnings are possible to disable.
>>
>> * I have removed some incorrect uses of SHARED_LIBRARY_FLAGS. This is 
>> included in our JDK LDFLAGS, so it should not be set separately, and 
>> definitely not as CFLAGS. (This caused compiler warnings, which now 
>> turned into errors.) However, a more suitable long-term solution is 
>> probably to move the knowledge of how to create shared libraries more 
>> specifically into SetupNativeCompilation, and not set it as part of 
>> the JDK flags.
>>
>> /Magnus
>