This patch mimics the behavior of Google Test and allow users to log custom messages after all flavors of ASSERT_ / EXPECT_.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
libc/test/UnitTest/LibcTest.h | ||
---|---|---|
53 | Do you know why the Matcher's interface cannot be const T&? Ideally it should not modify the inputs, right? |
- match should take a 'const T&' instead of a 'T&'
libc/test/UnitTest/LibcTest.h | ||
---|---|---|
53 | I traced it down to https://reviews.llvm.org/D75487 I refrained from fixing it in this patch to prevent noise but since you're mentioning it, here it is. |
LGTM with one question.
libc/test/UnitTest/TestLogger.cpp | ||
---|---|---|
69 | Why should we use [u]int<..>_t types? Could it lead to duplicate declaration errors, for example if int64_t == long long? |
- rebase
- Simplify implementation and add documentation
- match should take a 'const T&' instead of a 'T&'
- Use standard C types for TesLogger specializaions
libc/test/UnitTest/TestLogger.cpp | ||
---|---|---|
69 | You're right, thx for catching it. I've used the standard C types. |
Build bots were failing because of a few other bool r = EXPECT_FP_EQ(... and bool r = EXPECT_MPFR_MATCH_ROUNDING(... that I didn't catch.
They were only built when LLVM_LIBC_FULL_BUILD was not defined.
@lntue can you have another look?
Changed lines from last time you gave me LGTM : https://reviews.llvm.org/D152630?vs=531248&id=531265#toc
We should probably submit these math related changes as a separate patch BTW
Do you know why the Matcher's interface cannot be const T&? Ideally it should not modify the inputs, right?