On Wed, 2 Nov 2022 16:45:35 GMT, Julian Waters <[email protected]> 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
