RFR: 8296115: Allow for compiling the JDK with strict standards conformance [v4]

[Magnus Ihse Bursie]

On Wed, 2 Nov 2022 16:45:35 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499) proposes to set the -permissive- flag for the Microsoft Visual C++ compiler, to enforce strict standards conformance during compilation, making native code behave more strictly. While adding it to default builds is likely not practical given how much testing is required, as an option it can prove helpful in finding areas of native code that are not conformant to the standard. Instead of applying this to just one compiler, we can also include this for every compiler that has support for such a strict mode, which this change does.
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Export not required
>  - Merge remote-tracking branch 'upstream/master' into permissive
>  - Merge remote-tracking branch 'upstream/master' into permissive
>  - Merge remote-tracking branch 'upstream/master' into permissive
>  - Format
>  - Keep docs up to date
>  - New --enable-conforming-compilation option

Furthermore, I'm starting to wonder if it was such a great idea to combine this with the visual studio `/permissive-`. While the gcc/clang switches are about strict standards compliance, the visual studio switch is more of a "get the VS compiler more in line with other modern compilers", and Microsoft has explicitly warned that this will be enabled, then default, then the only choice, going forward. So this is really something we would want to see enabled all the time.

So, I am more or less proposing that we back this out, and that instead:

1) we try to enable `/permissive-` by default for Windows (this will require some code changes first)

2) we consider if we should raise the bar of "pedantictness" for clang, but with warnings we do not care about being turned off. (An alternative is that we explicitly turn on some selected additional warnings that we think are useful)

3) we entirely drops the idea that we could ever achieve anything like this for gcc, unless they up their game in having more finely grained warnings

4) and if you want to experiment with more strict compilation, to reach your goal of compiler/os-independence, you just use the standard method of `--with-extra-c-flags` to pass `-Wpedantict` etc.

-------------

PR: https://git.openjdk.org/jdk/pull/10912