On Wed, 9 Nov 2022 08:19:45 GMT, Julian Waters <[email protected]> wrote:
>> 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
@TheShermanTanker Yes, I think that would be the best way forward. Thank you
for taking care of it!
-------------
PR: https://git.openjdk.org/jdk/pull/10912
