This is an archive of the discontinued LLVM Phabricator instance.

[libc][test] Improve memory check reporting
Changes PlannedPublic

Authored by gchatelet on May 16 2023, 8:03 AM.

Details

Reviewers
courbet

Diff Detail

Event Timeline

gchatelet created this revision.May 16 2023, 8:03 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptMay 16 2023, 8:03 AM
gchatelet requested review of this revision.May 16 2023, 8:03 AM
gchatelet updated this revision to Diff 522629.
  • Remove leftover from debugging session
sivachandra added inline comments.
libc/test/src/string/memory_utils/memory_check_utils.h
111

I did not look enough to see if the logging parts are runtime code or test only code. If it is test only, may be add a comment saying that? If not, then a better approach is to use LIBC_ASSERT: https://github.com/llvm/llvm-project/blob/main/libc/src/__support/libc_assert.h

gchatelet added inline comments.May 16 2023, 10:19 AM
libc/test/src/string/memory_utils/memory_check_utils.h
111

I did not look enough to see if the logging parts are runtime code or test only code. If it is test only, may be add a comment saying that? If not, then a better approach is to use LIBC_ASSERT: https://github.com/llvm/llvm-project/blob/main/libc/src/__support/libc_assert.h

testing::tlog is the logging infrastructure that is used in LibUnitTest and this file is used in unit tests only (libc/*test*/src/string/memory_utils/memory_check_utils.h) so I think this is OK. Are you suggesting that I comment all testing::log lines in this file?

sivachandra added inline comments.May 16 2023, 10:30 AM
libc/test/src/string/memory_utils/memory_check_utils.h
111

Sorry, I did not compose my comment correctly. I should have said:

... if the logging parts are **for testing runtime code**...

What I meant was, if these messages are for catching test failures, then they should be in some EXPECT_* as the raw log messages do not come with line numbers. Or, if they are only providing assert like protection, using a real assert like LIBC_ASSERT is better because they also come with line numbers. About comments, if you do not want to use EXPECT_* macros, add comments why.

courbet added inline comments.May 16 2023, 11:52 PM
libc/test/src/string/memcmp_test.cpp
54

ASSERT_TRUE(CheckMemcmp<Impl>(span1, span2, size)) << "size=" << size; ?

gchatelet planned changes to this revision.May 17 2023, 12:44 AM
gchatelet marked an inline comment as done.
gchatelet added inline comments.
libc/test/src/string/memcmp_test.cpp
54

The libc version of ASSERT_* and EXPECT_* do not allow logging yet.

libc/test/src/string/memory_utils/memory_check_utils.h
111

Ha ok : ) Now I understand.

So this is indeed to catch test failures. I did not use EXPECT_* for several reasons:

  • Getting the faulty line in this function is not interesting for debugging as you need more context. For instance, the function can be called several times in one test and you really need to know which of the call site is failing (hence the ASSERT_TRUE in the test function).
  • The function is usually called in a loop to test many different configurations, EXPECT_* will produce a huge log making it hard to identify the root cause. It would need to be an ASSERT_* but it is only supposed to be called from the test itself since it returns.

Now another solution could be to use EXPECT_* here, to return false and to ASSERT_TRUE at the call site. But we would still need to log additional information. Currently, EXPECT_* and ASSERT_* do not allow logging.

I think the solution here is to create custom matchers.