Update GoogleTest to v1.14.0 #65823

zeroomega · 2023-09-08T23:56:48Z

This PR updates GoogleTest to v1.14.0
The LLVM specific modification over the GoogleTest can be seen from: https://gist.github.com/zeroomega/fb24b1d1c4252b852200e15fda29384d
List of removed GoogleTest files can be found:
https://gist.github.com/zeroomega/54d1da74aa5df9a22bf60474adc53cab

2 additional commits are required for the GoogleTest roll. Due to a change in how GoogleTest treats uninstantiated tests, any test added by TEST_P needs an corresponding INSTANTIATE_TEST_SUITE_P, otherwise an error will be reported. However, in LLVM, sometimes INSTANTIATE_TEST_SUITE_P calls were commented out to temporarily disable tests. In this case in v1.14.0, a GTEST_ALLOW_UNINSTANTIATED_PARAMETERIZED_TEST is needed to suppress the error. This macro did not exist in v1.10.0 so the change needs to land together with v1.14.0 roll to avoid build breakages.

The roll was tested under Linux x64 and Windows x64 and pass all tests under testing. It would be great if we can tests it under more build variants and hosts in LLVM bots before landing it.

I admit I cannot create a shellscript to do the auto roll. At least it was not possible without some non-trival refactoring to LLVM's patch and move these LLVM's additional functions into gtest_port.h/cc and gmock_port.h/cc. A better approach would be upstream LLVM's changes to GoogleTest so we can just keep a vanilla GoogleTest in LLVM (using git submodule).

The GoogleTest code also uses a different code style (Google C++ style instead of LLVM style). Shall I reformat the entire GoogleTest code base?

A few gtests were disabled by commenting out the INSTANTIATE_TEST_SUITE_P call to the tests. This causes test failures under GoogleTest v1.14.0 as by default, every TEST_P call without a corresponding INSTANTIATE_TEST_SUITE_P call will causes a failing test from GoogleTestVerification. This patch adds GTEST_ALLOW_UNINSTANTIATED_PARAMETERIZED_TEST calls to mitigate this problem.

Patch e7bd436 introduced `ImportMatrixType` and `ImportOpenCLPipe` but didn't enable them. This cases test failures under GoogleTest v1.14.0 as uninstantiated tests needs to be explicitly allowed using GTEST_ALLOW_UNINSTANTIATED_PARAMETERIZED_TEST call. This patch enables `ImportMatrixType` test and disable `ImportOpenCLPipe` test in preparation for GoogleTest v1.14.0.

This patch bumps GoogleTest to version 1.14.0

MaskRay · 2023-09-09T17:23:36Z

Thank you for the change! ninja check-llvm check-clang check-clang-tools check-flang check-mlir check-lld check-polly parses.

The GoogleTest code also uses a different code style (Google C++ style instead of LLVM style). Shall I reformat the entire GoogleTest code base?

I think we should just use the upstream style.

joker-eph

Agree with @MaskRay for the style: we should minimize the diff with upstream as much as possible!

third-party/unittest/CMakeLists.txt

petrhosek · 2023-09-09T21:45:58Z

third-party/unittest/CMakeLists.txt

+	  ARCHIVE DESTINATION "lib${LLVM_LIBDIR_SUFFIX}" COMPONENT llvm_gtest)
+  install(DIRECTORY googletest/include/gtest/ DESTINATION include/llvm-gtest/gtest/ COMPONENT llvm_gtest)
+  install(DIRECTORY googlemock/include/gmock/ DESTINATION include/llvm-gmock/gmock/ COMPONENT llvm_gtest)


This is undoing a change made recently in 91b3ca3. Is that intentional or was your checkout just stale?

My checkout just stales. Thanks for pointing it out.

petrhosek · 2023-09-09T21:47:44Z

third-party/unittest/googletest/README.LLVM

-This directory contains Google Test 1.10.0, with all elements removed except for
-the actual source code, to minimize the addition to the LLVM distribution.
+This directory contains Google Test 1.14.0,
+revision `f8d7d77c06936315286eb55f8de22cd23c188571`, with all elements removed


We don't include the revision in the googlemock README.LLVM file so I'd avoid it here also for consistency (or include it in the other one as well).

Parts of the googletest documentation claim to follow a "live at HEAD" philosophy, so a hash reference (here and in the other README) seems appropriate. Although using a tag, if there is one, would be preferable.

v1.14.0 is a valid tag and f8d7d77c06936315286eb55f8de22cd23c188571 is the revision that it resolves to. The content matches the 1.14.0 source tar ball. The reason that I include a hash here is because the previous roll v1.10.0 doesn't have a valid tag and I had a bit hard time to find the correct revision for doing a diff to see what LLVM have patched. Since v1.14.0 is a valid tag, I think it is appropriate to remove the hash and just leave v1.14.0 in the doc.

pogo59

Nice to see the LLVM intrusion into googletest proper is very minimized!

IME, testing on Linux with both gcc and clang as build compilers is very helpful. With Windows/MSVC that covers the three main cases.

pogo59 · 2023-09-11T13:33:07Z

third-party/unittest/googlemock/README.LLVM

@@ -10,14 +10,10 @@ Cleaned up as follows:
 # Remove all the unnecessary files and directories
 $ rm -f CMakeLists.txt configure* Makefile* CHANGES CONTRIBUTORS README README.md .gitignore
 $ rm -rf build-aux make msvc scripts test docs
-$ rm -f `find . -name \*\.pump`
 $ rm -f src/gmock_main.cc

 # Put the license in the consistent place for LLVM.
 $ mv LICENSE LICENSE.TXT

 Modified as follows:
 * Support for std::begin/std::end in gmock-matchers.h


Is this still true? If it is, it sounds like the kind of patch that ought to be made in upstream googletest. If not, please remove this line.

Yes, gmock-matchers.h still have this part patched, see https://gist.github.com/zeroomega/fb24b1d1c4252b852200e15fda29384d#file-gtest_llvm_modification-patch-L251 . When locally test it, without the patch, LLVM unit tests will have build errors.

That seems odd, and worth following up with upstream googletest. In the meantime, I think it would be clearer to future maintainers if we did something to clearly identify the code blocks that were changed, and why. For example,
// LLVM local change to support std::begin/std::end
followed by the new code, and then the old code commented-out. That way diffs will provide clues, and merges/commits will have conflicts that someone will need to sort out properly.

I put the local changes into commented blocks in change in amend commit: 2fe51a3 in this PR, please take a look.

I looked at that specific commit, seems fine.

pogo59 · 2023-09-11T13:45:55Z

third-party/unittest/googletest/README.LLVM

 $ rm -f src/gtest_main.cc

 # Put the license in the consistent place for LLVM.
 $ mv LICENSE LICENSE.TXT

 Modified as follows:
-* Added support for NetBSD, Minix and Haiku.
 * Added raw_os_ostream support to include/gtest/internal/custom/gtest-printers.h.
 * Added StringRef support to include/gtest/internal/custom/gtest-printers.h.


Also include/gtest/gtest-message.h and include/gtest/gtest-printers.h. Probably worth saying something like "(see uses of llvm_gtest)" to help the next person doing a roll.

I added a description for the these two headers.

pogo59 · 2023-09-11T13:48:02Z

third-party/unittest/googletest/README.LLVM

-This directory contains Google Test 1.10.0, with all elements removed except for
-the actual source code, to minimize the addition to the LLVM distribution.
+This directory contains Google Test 1.14.0,
+revision `f8d7d77c06936315286eb55f8de22cd23c188571`, with all elements removed


Parts of the googletest documentation claim to follow a "live at HEAD" philosophy, so a hash reference (here and in the other README) seems appropriate. Although using a tag, if there is one, would be preferable.

Bump googletest to v1.14.0 This patch bumps GoogleTest to version 1.14.0

zeroomega · 2023-09-11T20:55:50Z

I have addressed all review comments in the the latest amend commits. Please take a look.

zeroomega · 2023-09-12T00:09:04Z

I have locally tested this PR using gcc 12.2.0 on Linux x64 and MSVC from VS2019, both passed without issues. @pogo59 Do you have any concerns or suggestions before we merge this?

pogo59 · 2023-09-12T15:27:20Z

I'm happy with this, the bots will catch any environmental issues that you haven't found yet. LGTM.

zeroomega · 2023-09-12T17:48:52Z

First bot failure: https://lab.llvm.org/buildbot/#/builders/127/builds/55068

[18/126] Generating SANITIZER_TEST_OBJECTS.sanitizer_lzw_test.cpp.x86_64.o
FAILED: projects/compiler-rt/lib/sanitizer_common/tests/SANITIZER_TEST_OBJECTS.sanitizer_lzw_test.cpp.x86_64.o C:/b/slave/sanitizer-windows/build/stage1/projects/compiler-rt/lib/sanitizer_common/tests/SANITIZER_TEST_OBJECTS.sanitizer_lzw_test.cpp.x86_64.o 
cmd.exe /C "cd /D C:\b\slave\sanitizer-windows\build\stage1\projects\compiler-rt\lib\sanitizer_common\tests && C:\b\slave\sanitizer-windows\build\stage1\.\bin\clang.exe -DGTEST_NO_LLVM_SUPPORT=1 -DGTEST_HAS_RTTI=0 -IC:/b/slave/sanitizer-windows/llvm-project/llvm/../third-party/unittest/googletest/include -IC:/b/slave/sanitizer-windows/llvm-project/llvm/../third-party/unittest/googletest -Wno-deprecated-declarations -DGTEST_NO_LLVM_SUPPORT=1 -DGTEST_HAS_RTTI=0 -IC:/b/slave/sanitizer-windows/llvm-project/llvm/../third-party/unittest/googlemock/include -IC:/b/slave/sanitizer-windows/llvm-project/llvm/../third-party/unittest/googlemock -IC:/b/slave/sanitizer-windows/llvm-project/compiler-rt/include -IC:/b/slave/sanitizer-windows/llvm-project/compiler-rt/lib -IC:/b/slave/sanitizer-windows/llvm-project/compiler-rt/lib/sanitizer_common -DSANITIZER_COMMON_NO_REDEFINE_BUILTINS -fno-rtti -O2 -Werror=sign-compare -Wno-gnu-zero-variadic-macro-arguments -gline-tables-only -gcodeview -c -o SANITIZER_TEST_OBJECTS.sanitizer_lzw_test.cpp.x86_64.o C:/b/slave/sanitizer-windows/llvm-project/compiler-rt/lib/sanitizer_common/tests/sanitizer_lzw_test.cpp"
C:/b/slave/sanitizer-windows/llvm-project/compiler-rt/lib/sanitizer_common/tests/sanitizer_lzw_test.cpp:22:10: error: no member named 'generate' in namespace 'std'
   22 |     std::generate(data.begin(), data.end(), gen);
      |     ~~~~~^

Probably caused by missing include header. This will be addressed by 063cd55.
The header was included by googletest/include/gtest/internal/gtest-port.h in v.1.10.0 but it was removed in v1.14.0

bogner · 2023-09-12T18:37:24Z

I'm seeing some unused functions in files that haven't been changed in years, which I'm guessing come from this update - did the new googletest change how custom output works?

llvm/unittests/Support/JSONTest.cpp:490:27: error: unused function 'operator<<' [-Werror,-Wunused-function]
inline llvm::raw_ostream &operator<<(llvm::raw_ostream &OS,
                          ^
1 error generated.

I guess we can just delete this function, but I'm not sure if it means we've degraded the error messages for these tests or anything like that.

zeroomega · 2023-09-12T18:41:32Z

I'm seeing some unused functions in files that haven't been changed in years, which I'm guessing come from this update - did the new googletest change how custom output works?
llvm/unittests/Support/JSONTest.cpp:490:27: error: unused function 'operator<<' [-Werror,-Wunused-function]
inline llvm::raw_ostream &operator<<(llvm::raw_ostream &OS,
                          ^
1 error generated.
I guess we can just delete this function, but I'm not sure if it means we've degraded the error messages for these tests or anything like that.

Yes new gtest changes how customized function work. These functions either need to be deleted or revised.

I plan to revert this roll as I am seeing some linker error in bots:

FAILED: compiler-rt/lib/fuzzer/tests/FuzzerUtils-aarch64-Test /b/sanitizer-aarch64-linux-fuzzer/build/llvm_build0/runtimes/runtimes-bins/compiler-rt/lib/fuzzer/tests/FuzzerUtils-aarch64-Test
cd /b/sanitizer-aarch64-linux-fuzzer/build/llvm_build0/runtimes/runtimes-bins/compiler-rt/lib/fuzzer/tests && /b/sanitizer-aarch64-linux-fuzzer/build/llvm_build0/./bin/clang++ FuzzedDataProviderTestObjects.FuzzedDataProviderUnittest.cpp.aarch64.o FuzzedDataProviderTestObjects.gtest-all.cc.aarch64.o -o /b/sanitizer-aarch64-linux-fuzzer/build/llvm_build0/runtimes/runtimes-bins/compiler-rt/lib/fuzzer/tests/./FuzzerUtils-aarch64-Test -fuse-ld=lld -Wl,--color-diagnostics -Wthread-safety -Wthread-safety-reference -Wthread-safety-beta --driver-mode=g++ -lpthread -nostdlib++ -fno-exceptions /b/sanitizer-aarch64-linux-fuzzer/build/llvm_build0/runtimes/runtimes-bins/compiler-rt/lib/fuzzer/libcxx_fuzzer_aarch64/lib/libc++.a -march=armv8-a
ld.lld: error: undefined symbol: testing::internal2::PrintBytesInObjectTo(unsigned char const*, unsigned long, std::__Fuzzer::basic_ostream<char, std::__Fuzzer::char_traits<char>>*)
>>> referenced by gtest-printers.h:158 (/b/sanitizer-aarch64-linux-fuzzer/build/llvm-project/runtimes/../third-party/unittest/googletest/include/gtest/gtest-printers.h:158)
>>>               FuzzedDataProviderTestObjects.FuzzedDataProviderUnittest.cpp.aarch64.o:(std::__Fuzzer::basic_string<char, std::__Fuzzer::char_traits<char>, std::__Fuzzer::allocator<char>> testing::internal::FormatForComparisonFailureMessage<FuzzedDataProvider_ConsumeEnum_Test::TestBody()::Enum, FuzzedDataProvider_ConsumeEnum_Test::TestBody()::Enum>(FuzzedDataProvider_ConsumeEnum_Test::TestBody()::Enum const&, FuzzedDataProvider_ConsumeEnum_Test::TestBody()::Enum const&))
clang++: error: linker command failed with exit code 1 (use -v to see invocation)

It will need some time to debug.

This reverts commit 54c1a9b. It breaks a few llvm bots.

zeroomega · 2023-09-12T22:24:54Z

I looked into the "unused functions" issue shown up in bots like: https://lab.llvm.org/buildbot/#/builders/57/builds/29853 .

The root cause is that GoogleTest changed the way it converts an arbitrary object into string. In the past, any object that cannot be printed to the string will eventually matched to function at

llvm-project/third-party/unittest/googletest/include/gtest/gtest-printers.h

Line 264 in 58d50b0

void DefaultPrintNonContainerTo(const T& value, ::std::ostream* os) {

. Then the call to the llvm_gtest::printable will use OS << V.V; to print the value to the stream, if the object overrides its << operator, like

llvm-project/clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp

Line 457 in 58d50b0

friend llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, const Tag &T) {

, it will be used to convert the object to string. If not, a build error will happen. In GoogleTest v1.14.0, the object to string logic is re-written and for an arbitrary object, it will eventually matched to RawBytesPrinter defined at

llvm-project/third-party/unittest/googletest/include/gtest/gtest-printers.h

Line 290 in 54c1a9b

struct RawBytesPrinter {

. Therefore, the operator<< override won't be used and a unused function warnig(error) will be thrown.

So deleting these llvm::raw_ostream &operator<< functions won't cause any test failure but it will degrade the error message output since now the objects were printed as raw bytes. @bogner FYI.

zeroomega · 2023-09-13T19:06:49Z

I look through all the bot failures from my mail box and I think so far there are two issues:

error: unused function 'operator<<' issue, this is caused by a type matching bug I introduced in the roll and it will be addressed by: c7e1a49
Linker error and SEGV in runtimes bots (e.g. https://lab.llvm.org/buildbot/#/builders/240/builds/15001 andhttps://lab.llvm.org/buildbot/#/builders/239/builds/3686). These are caused by an incremental build bug in runtimes build. I can reproduce these errors locally on my machine if I do an incremental build after the roll and the issue is cleared if I did a clean build. I filed bug: runtimes incremental build didn't rebuild GoogleTest when it is changed #66272

I plan to reland the roll after it passes more local tests. For the incremental build bug, I plan to manually trigger a clean build once these runtimes bots pick up my change. Please let me know if you have questions and comments.

This patch reland 54c1a9b, which updates GoogleTest to v1.14.0. This patch fixes bots failures caused by the early patch.

zeroomega · 2023-09-13T21:19:00Z

Relanded as a866ce7. I will monitor the bots and manually trigger clean build if linker error appears again.

mikaelholmen · 2023-09-14T08:16:59Z

I see compilation problems with this patch.
By mistake I originally posted about the problems in
#66268 (comment)

So the problem: On a RHEL7 server we see stuff like:
In file included from /repo/uabelho/dev-main/compiler-rt/lib/memprof/tests/driver.cpp:9: In file included from /repo/uabelho/dev-main/runtimes/../third-party/unittest/googletest/include/gtest/gtest.h:65: In file included from /repo/uabelho/dev-main/runtimes/../third-party/unittest/googletest/include/gtest/gtest-death-test.h:43: In file included from /repo/uabelho/dev-main/runtimes/../third-party/unittest/googletest/include/gtest/internal/gtest-death-test-internal.h:47: /repo/uabelho/dev-main/runtimes/../third-party/unittest/googletest/include/gtest/gtest-matchers.h:728:50: error: too few template arguments for class template 'equal_to' 728 | : ComparisonBase<EqMatcher<Rhs>, Rhs, std::equal_to<>>(rhs) {} | ^ /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stl_function.h:204:12: note: template is declared here 203 | template<typename _Tp> | ~~~~~~~~~~~~~~~~~~~~~~ 204 | struct equal_to : public binary_function<_Tp, _Tp, bool> | ^
so it looks like it's when it's using the newly built clang to compile
compiler-rt/lib/memprof/tests/driver.cpp
it's using header files from the host and those headers are too old for the updated GoogleTest.

If we don't build builtins (LLVM_BUILTIN_TARGETS) I don't see any problems.

mikaelholmen · 2023-09-14T12:53:41Z

Ok, seems like the only problem is the MemProf unit test
compiler-rt/lib/memprof/tests/

So if I manually disable that I don't see any other failures with this patch.

zeroomega · 2023-09-14T17:48:47Z

Ok, seems like the only problem is the MemProf unit test compiler-rt/lib/memprof/tests/

So if I manually disable that I don't see any other failures with this patch.

I think any components that uses freshly built clang (stage1) could potentially run into this problem again, the correct way to solve it is to provide a compatible C++ Library to the freshly built clang when it built compiler-rt and related tests. For example, use -D with RUNTIMES_${target}_CMAKE_CXX_FLAGS and RUNTIMES_${target}_CMAKE_CXX_FLAGS to pass --gcc-toolchain (it might be deprecated and there is an updated flag for it) to the runtimes build. This will probably allow stage1 clang to use gcc's stdlib like your bootstrap clang.

bjope · 2023-09-14T19:44:00Z

Ok, seems like the only problem is the MemProf unit test compiler-rt/lib/memprof/tests/
So if I manually disable that I don't see any other failures with this patch.

I think any components that uses freshly built clang (stage1) could potentially run into this problem again, the correct way to solve it is to provide a compatible C++ Library to the freshly built clang when it built compiler-rt and related tests. For example, use -D with RUNTIMES_${target}_CMAKE_CXX_FLAGS and RUNTIMES_${target}_CMAKE_CXX_FLAGS to pass --gcc-toolchain (it might be deprecated and there is an updated flag for it) to the runtimes build. This will probably allow stage1 clang to use gcc's stdlib like your bootstrap clang.

Thanks! Yes, I think we hadn't considered that some things we set up for the regular build wasn't forwarded to the compiler-rt test.
When setting
-DRUNTIMES_${target}_COMPILER_RT_TEST_COMPILER_CFLAGS=--gcc-toolchain=<path-to-toolchain>
the problem @mikaelholmen mentioned disappeared. I haven't tried adding it to CMAKE_CXX_FLAGS, but maybe that is a better option.

This PR updates GoogleTest to v1.14.0 . It also updates the Clang ASTTest to fix a compatibility issue with the new GoogleTest.

This reverts commit 54c1a9b. It breaks a few llvm bots.

This patch reland 54c1a9b, which updates GoogleTest to v1.14.0. This patch fixes bots failures caused by the early patch.

zmodem · 2023-09-28T18:32:29Z

We're seeing unit test crashes on Windows when building with rpmalloc (via LLVM_INTEGRATED_CRT_ALLOC). It's crashing here: https://github.com/google/googletest/blob/v1.14.0/googletest/include/gtest/internal/gtest-port.h#L2092

@aganea have you also hit this?

(Our bug: https://crbug.com/1487548)

aganea · 2023-09-28T18:51:09Z

@zmodem Can you add ENABLE_ASSERTS on this line and run the test again, see if that gives something interesting?

zmodem · 2023-09-28T19:03:18Z

Just tried it, but I didn't hit any asserts.

The new implementation was brought in with the gtest update in a866ce7, but it crashes when building with rpmalloc, see #65823 (comment) Comment out the new implementation basically gives us the code before the gtest update.

petrhosek · 2023-09-29T08:10:43Z

We have seen occasional segfaults when using rpmalloc in other tools such as GN and Ninja which we haven't been able to get to the bottom of so we eventually switched to another allocator. It's possible that it's the same issue here, in which case perhaps we should reconsider our support for rpmalloc.

The new implementation was brought in with the gtest update in a866ce7, but it crashes when building with rpmalloc, see llvm#65823 (comment) Comment out the new implementation basically gives us the code before the gtest update.

aganea · 2023-09-29T12:28:21Z

@zmodem I haven’t been able to repro with the recipe posted on https://crbug.com/1487548. I am using latest rpmalloc (main branch), latest VS 2022, latest WinSDK. I am running on Win11, on a AMD Ryzen9 CPU. Are you running on WinServer2022? Are able to give more precision on the conditions for reproducing?

zmodem · 2023-09-29T12:36:03Z

I believe we're on the 10.0.19041.0 (2020-04) SDK and VS 16.6.1, running on Windows 10. The rpmalloc version is bc1923f which is probably old by now.

I'll try with the latest rpmalloc version, and will also see if I can dig into the stl headers a bit, but I won't be able to get to this today.

aganea · 2023-09-30T18:38:14Z

I managed to repro. Updating to latest rpmalloc doesn't help. It is actually this, still open, issue: microsoft/STL#1066

zeroomega added 3 commits September 8, 2023 15:27

Bump googletest to v1.14.0

ac0785c

This patch bumps GoogleTest to version 1.14.0

zeroomega requested review from petrhosek, MaskRay and pogo59 September 8, 2023 23:56

zeroomega requested a review from a team as a code owner September 8, 2023 23:56

github-actions bot added the clang Clang issues not falling into any other category label Sep 8, 2023

MaskRay approved these changes Sep 9, 2023

View reviewed changes

joker-eph approved these changes Sep 9, 2023

View reviewed changes

petrhosek reviewed Sep 9, 2023

View reviewed changes

third-party/unittest/CMakeLists.txt Outdated Show resolved Hide resolved

petrhosek reviewed Sep 9, 2023

View reviewed changes

pogo59 reviewed Sep 11, 2023

View reviewed changes

zeroomega force-pushed the gtest-roll branch from 680d1aa to ac0785c Compare September 11, 2023 18:32

zeroomega added 2 commits September 11, 2023 13:09

amend! Bump googletest to v1.14.0

745a762

Bump googletest to v1.14.0 This patch bumps GoogleTest to version 1.14.0

amend! amend! Bump googletest to v1.14.0

2fe51a3

Bump googletest to v1.14.0 This patch bumps GoogleTest to version 1.14.0

petrhosek approved these changes Sep 11, 2023

View reviewed changes

zeroomega merged commit 54c1a9b into llvm:main Sep 12, 2023

zeroomega added a commit that referenced this pull request Sep 12, 2023

Revert "Update GoogleTest to v1.14.0 (#65823)"

499d713

This reverts commit 54c1a9b. It breaks a few llvm bots.

vzakhari mentioned this pull request Sep 12, 2023

internap proc trampolines #66156

Closed

zeroomega added a commit that referenced this pull request Sep 13, 2023

Reland "Update GoogleTest to v1.14.0 (#65823)"

a866ce7

This patch reland 54c1a9b, which updates GoogleTest to v1.14.0. This patch fixes bots failures caused by the early patch.

zeroomega mentioned this pull request Sep 14, 2023

gmock-matchers.h patch could be upstreamed to googletest #66268

Open

ZijunZhaoCCK pushed a commit to ZijunZhaoCCK/llvm-project that referenced this pull request Sep 19, 2023

Update GoogleTest to v1.14.0 (llvm#65823)

cdc51bc

This PR updates GoogleTest to v1.14.0 . It also updates the Clang ASTTest to fix a compatibility issue with the new GoogleTest.

ZijunZhaoCCK pushed a commit to ZijunZhaoCCK/llvm-project that referenced this pull request Sep 19, 2023

Revert "Update GoogleTest to v1.14.0 (llvm#65823)"

f6bbd56

This reverts commit 54c1a9b. It breaks a few llvm bots.

ZijunZhaoCCK pushed a commit to ZijunZhaoCCK/llvm-project that referenced this pull request Sep 19, 2023

Reland "Update GoogleTest to v1.14.0 (llvm#65823)"

3cc8a2c

This patch reland 54c1a9b, which updates GoogleTest to v1.14.0. This patch fixes bots failures caused by the early patch.

MaskRay mentioned this pull request Jan 30, 2024

[SingleSource/Atomic] Add preliminary tests for atomic builtins. llvm/llvm-test-suite#78

Closed

Update GoogleTest to v1.14.0 #65823

Update GoogleTest to v1.14.0 #65823

Conversation

zeroomega commented Sep 8, 2023

MaskRay commented Sep 9, 2023

joker-eph left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pogo59 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zeroomega commented Sep 11, 2023

zeroomega commented Sep 12, 2023

pogo59 commented Sep 12, 2023

zeroomega commented Sep 12, 2023 • edited Loading

bogner commented Sep 12, 2023

zeroomega commented Sep 12, 2023

zeroomega commented Sep 12, 2023

zeroomega commented Sep 13, 2023

zeroomega commented Sep 13, 2023

mikaelholmen commented Sep 14, 2023

mikaelholmen commented Sep 14, 2023

zeroomega commented Sep 14, 2023

bjope commented Sep 14, 2023

zmodem commented Sep 28, 2023

aganea commented Sep 28, 2023

zmodem commented Sep 28, 2023

petrhosek commented Sep 29, 2023

aganea commented Sep 29, 2023

zmodem commented Sep 29, 2023

aganea commented Sep 30, 2023 • edited Loading

zeroomega commented Sep 12, 2023 •

edited

Loading

aganea commented Sep 30, 2023 •

edited

Loading