Add gtest support on jdk15+

[zzambers]

Adds gtest support for testimage on jdk15+. (in-tree gtest was removed in jdk15) This is needed for some hotspot tests.

Fixes #3956

Testing:
Tested locally on rhel-8 using command:
./makejdk-any-platform.sh -J /usr/lib/jvm/java-17-openjdk --use-adoptium-devkit gcc-11.3.0-Centos7.9.2009-b03 --build-variant temurin jdk17u
( fixed the issue, build passed, gtest files appeared in test-image in hotspot/gtest )

[judovana]

I worte it quite clumsy. To keep the build offline, but still built gtests by default, I would like to see something like

if  [ -e gtests ] ; then
   addConfigureArg "--with-gtest=...."
else
  if getstAllowed ; then
     downloadGtests
     addConfigureArg "--with-gtest=...."
  fi
fi

where getstAllowed shoudl be true by default, and only if user of build.sh passes something like --no-gtests, or if test image creation is disabled by other logic, it should be false.... wdyt?

[zzambers]

I worte it quite clumsy. To keep the build offline, but still built gtests by default, I would like to see something like

if  [ -e gtests ] ; then
   addConfigureArg "--with-gtest=...."
else
  if getstAllowed ; then
     downloadGtests
     addConfigureArg "--with-gtest=...."
  fi
fi

where getstAllowed shoudl be true by default, and only if user of build.sh passes something like --no-gtests, or if test image creation is disabled by other logic, it should be false.... wdyt?

I think download should be kept in prepareWorkspace.sh, but gtest support can be made conditional..

[zzambers]

Thanks for feedback, I have made gtest optional. Tested (same way as originally + with --skip-gtest), behaves as expected.

[judovana]

Thanx!! Looks nice to me :)

[judovana]

Just side note, you tried that image in jtregs then, right?

[judovana]

@zzambers Why the checks had not run the build of openjdk? Maybe you need to refresh yours actions setup?

[zzambers]

Just side note, you tried that image in jtregs then, right?

I have not tried to run jtregs with generated image, just examined that libraries for gtest are there.

[zzambers]

Results in GHA appeared, there i build failure on windows jdk17u (other ones pass). I looked into it a bit:

Error:

d:\a\temurin-build\temurin-build\workspace\build\src\test\hotspot\gtest\metaprogramming\test_enableIf.cpp(73): error C2244: 'TestEnableIfNested<T>::sub1': unable to match function definition to an existing declaration
d:\a\temurin-build\temurin-build\workspace\build\src\test\hotspot\gtest\metaprogramming\test_enableIf.cpp(73): note: see declaration of 'TestEnableIfNested<T>::sub1'
d:\a\temurin-build\temurin-build\workspace\build\src\test\hotspot\gtest\metaprogramming\test_enableIf.cpp(73): note: definition
d:\a\temurin-build\temurin-build\workspace\build\src\test\hotspot\gtest\metaprogramming\test_enableIf.cpp(73): note: 'U TestEnableIfNested<T>::sub1(U)'
d:\a\temurin-build\temurin-build\workspace\build\src\test\hotspot\gtest\metaprogramming\test_enableIf.cpp(73): note: existing declarations
d:\a\temurin-build\temurin-build\workspace\build\src\test\hotspot\gtest\metaprogramming\test_enableIf.cpp(68): note: 'U TestEnableIfNested<T>::sub1(U)'
make[3]: *** [lib/CompileGtest.gmk:88: /cygdrive/d/a/temurin-build/temurin-build/workspace/build/src/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/gtest/objs/test_enableIf.obj] Error 1

Details:
Problem is reproducible (even with older gtest). It fails to compile code introduced in JDK-8258853. Change was not backported to jdk11u, that's why windows build passes there. Build also passes on jdk (newest). I don't see any changes to relevant code in jdk, so I think it is because Visual Studio 2022 is used for jdk, while jdk17u uses Visual Studio 2019.

(Could be bug in older VS (2019), if other systems and also newer VS are not affected. Not yet sure, what to do about it.)

[zzambers]

Correction:
All windows builds use VS 2022. Even though GHA workflow installs VS 2019 on jdk11u and jdk17u, configure output shows, that VS 2022 is actually used everywhere:

* Toolchain:      microsoft (Microsoft Visual Studio 2022)
* C Compiler:     Version 19.42.34436 (at /cygdrive/c/progra~1/micros~2/2022/enterp~1/vc/tools/msvc/1442~1.344/bin/hostx86/x64/cl.exe)
* C++ Compiler:   Version 19.42.34436 (at /cygdrive/c/progra~1/micros~2/2022/enterp~1/vc/tools/msvc/1442~1.344/bin/hostx86/x64/cl.exe)

[zzambers]

I have done quite a lot of testing locally with VS 2022 today and found, that jdk17 build actually passes with older version of VS 2022:

configure: Using microsoft C compiler version 19.37.32825 [Microsoft (R) C/C++ Optimizing Compiler Version 19.37.32825 for x64]
...
configure: Using microsoft C++ compiler version 19.37.32825 [Microsoft (R) C/C++ Optimizing Compiler Version 19.37.32825 for x64]
...
* Toolchain:      microsoft (Microsoft Visual Studio 2022)
* C Compiler:     Version 19.37.32825 (at /cygdrive/c/progra~1/micros~1/2022/commun~1/vc/tools/msvc/1437~1.328/bin/hostx86/x64/cl.exe)
* C++ Compiler:   Version 19.37.32825 (at /cygdrive/c/progra~1/micros~1/2022/commun~1/vc/tools/msvc/1437~1.328/bin/hostx86/x64/cl.exe)

However, after I updated VS 2022, build failed. Versions after update:

configure: Using microsoft C compiler version 19.43.34808 [Microsoft (R) C/C++ Optimizing Compiler Version 19.43.34808 for x64]
...
configure: Using microsoft C++ compiler version 19.43.34808 [Microsoft (R) C/C++ Optimizing Compiler Version 19.43.34808 for x64]
...
* Toolchain:      microsoft (Microsoft Visual Studio 2022)
* C Compiler:     Version 19.43.34808 (at /cygdrive/c/progra~1/micros~1/2022/commun~1/vc/tools/msvc/1443~1.348/bin/hostx86/x64/cl.exe)
* C++ Compiler:   Version 19.43.34808 (at /cygdrive/c/progra~1/micros~1/2022/commun~1/vc/tools/msvc/1443~1.348/bin/hostx86/x64/cl.e

Btw jdk21u is also affected (but latest jdk is not).

I have tried to manually apply some changes to relevant files done in newer jdks (to see if I can work around this somehow). There are only small changes (things like sorting includes...) Did not help (maybe changes in another included files?).

There was one change JDK-8347909, which does something about precompiled headers. This gave me an idea to try to run build with --disable-precompiled-headers, but build still failed.. :(

Summary:

• seems like bug in recent updates of VS 2022
• I still don't know why (latest) jdk is not affected, while jdk17u and jdk21u are affected (could be some special set of conditions, which triggers bug in VS 2022)

[zzambers]

I am now in process of bisecting jdk commit, which fixes this issue on newer jdks. (hopefully it will put more light on the problem)

[zzambers]

And the winner is JDK-8317132 :)

I don't see any change to relevant code, so it seems like adding -permissive- argument to compiler avoids the issue in newer jdks. This disables permissive mode and sets compiler to strict/standard-conforming behavior according to doc. (notice - in the end)

That is interesting, I would expect permissive mode to be more forgiving and not to fail, where strict/standard-conforming mode passes. I think, it is probably not supposed to be like that and that it is likely bug in VS compiler. I'll probably fill issue to Visual Studio later.

[zzambers]

I have filled issue for Visual Studio: https://developercommunity.visualstudio.com/t/OpenJDK-jdk17u-build-failure-with-VS20/10860335

[FrankXie05]

@zzambers Thanks for you posting feedback.

Sorry for leaving a comment here. I saw your feedback and I think it might be more convenient to communicate here.

I think:
The inconsistent declarations of functions ENABLE_IF and ENABLE_IF_SDEFN may cause MSVC parsing failure.

https://github.com/openjdk/jdk17u/blob/ae0177b6abc1c4b3755ec446f2f35ad2616107a9/test/hotspot/gtest/metaprogramming/test_enableIf.cpp#L55

https://github.com/openjdk/jdk17u/blob/ae0177b6abc1c4b3755ec446f2f35ad2616107a9/test/hotspot/gtest/metaprogramming/test_enableIf.cpp#L58

And the stricter SFINAE parsing of MSVC in /permissive- mode may also cause ENABLE_IF parsing failure, especially sub2.

Could you please provide a simple example of this problem? It can be a .cpp or .i file (the file can be replied to Feedbcak).
This way we can locate the problem of a VS version more quickly, and we will solve it quickly. :)

Thanks,
Frank