On Fri, Apr 2, 2021 at 10:47 AM Shuah Khan skhan@linuxfoundation.org wrote:
On 4/2/21 3:35 AM, Brendan Higgins wrote:
On Fri, Feb 5, 2021 at 2:18 PM Daniel Latypov dlatypov@google.com wrote:
Before:
Expected str == "world", but str == hello "world" == world
After:
Expected str == "world", but str == "hello"
<we don't need to tell the user that "world" == "world">
Note: like the literal ellision for integers, this doesn't handle the case of KUNIT_EXPECT_STREQ(test, "hello", "world") since we don't expect it to realistically happen in checked in tests. (If you really wanted a test to fail, KUNIT_FAIL("msg") exists)
In that case, you'd get:
Expected "hello" == "world", but
<output for next failure>
Signed-off-by: Daniel Latypov dlatypov@google.com
Reviewed-by: Brendan Higgins brendanhiggins@google.com
Hi Daniel,
Please run checkpatch on your patches in the future. I am seeing a few checkpatch readability type improvements that can be made.
Please make changes and send v2 with Brendan's Reviewed-by.
Are there some flags you'd like me to pass to checkpatch?
$ ./scripts/checkpatch.pl --git HEAD total: 0 errors, 0 warnings, 42 lines checked
Commit f66884e8b831 ("kunit: make KUNIT_EXPECT_STREQ() quote values, don't print literals") has no obvious style problems and is ready for submission.
I just rebased onto linus/master again since I know checkpatch.pl's default behavior had changed recently, but I didn't see any errors there.
I know this commit made some lines go just over 80 characters, so $ ./scripts/checkpatch.pl --max-line-length=80 --git HEAD ... total: 0 errors, 4 warnings, 42 lines checked
I can go and line wrap these but had figured they were more readable this way if checkpatch.pl no longer complained by default.
Thanks, Daniel
thanks, -- Shuah