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

[Julian Waters]

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

> I experimented with enabling this for GHA, and it turned out that there are huge efforts needed to even make the code base compile with this flag turned on. I'm starting to wonder if it was such a great idea to introduce this, after all. I realize I did a poor job when reviewing this to ask if this did compile. Well, I can tell now, it does not. For gcc, it seems practically impossible to ever get it to work, since all hotspot constructs such as
> 
> ```
> DEBUG_ONLY(if (checkResult) log_trace("Checked"));
> ```
> 
> which are very common, will result in a warning about a superfluous semicolon in non-debug builds. (And similar for `AARCH64_ONLY(...);` etc).
> 
> For clang, this warning of semi-colon could be turned off separately, which -- combined with some other disabled warnings -- made it possible to compile. However, the code it complained about was in most cases fine, it was just using non-standard gcc or clang extensions to the C++ standard. We really need to raise this to a discussion if this should be considered a problem.
> 
> Here is a commit showing most (but not all) of the changes needed to make clang compile on macOS with the new conformance option turned on: [793c57a](https://github.com/openjdk/jdk/commit/793c57a8986c7875b4913b6eabbaef8baab23e3e)
> 
> I think some of these warnings are definitely legit, like `import-preprocessor-directive-pedantic` (where the code uses `#import` instead of `#include`) or `c++17-extensions` (we should not include code that is beyond C++14, at least not in this point in time). But most are complaints about benign use of gcc/clang extensions.
> 
> And the pedantic modes of gcc is really, really cranky. And it can't be piecewise turned off like clang, so as I said, I doubt this can ever get to work.
> 
> (Taggning @kimbarrett since I know you are interested in such questions)

Oh dear, I was expecting several issues with gcc but it seems like I _grossly_ underestimated just how strict it would be. I'll back this out and reopen [8241499](https://bugs.openjdk.org/browse/JDK-8241499) if there aren't any objections to that, since this is my mess to clean up. From what I've tested -permissive- didn't really break anything, so it should be trivial to change that to just be on by default instead of through a flag (Testing not considered, at least)

> c++17-extensions (we should not include code that is beyond C++14, at least not in this point in time).

There are plans for having code compatibility past C++14? Unlike the permissive switch, from what I've tested a large chunk of java.desktop code is really not happy with anything C++17 or above, so that would be a really big problem if so

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

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