Add extra output for the mismatch cases to show where bitmap
mismatches are ocurring.
Details
- Reviewers
- None
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I see the idea to give some immediate improvement but I think there's more to be done to inform the user properly:
- Convert all of the runs of ASSERT_TRUE to individual tests using a test fixture (or two), for example [0]
- Creating a custom assertion message that includes the CPU name and the feature [1]
- Treating the features as a set, so we can say in one go "the features <list> are missing", instead of a one by one check
- Printing feature names when we do find a missing bit, you an ask the target parser for that
But I get that that's more than you bargained for.
I think the messages as they stand only help local development, where you know what you broke because you're adding a CPU.
If I'm working on seemingly unrelated code, I don't see how these messages give me any more info than the single gtest failure we have now.
Like ok the ARM cpus test failed on this bit. Ok. What does that mean?
Also I'm not a fan of random errs messages in buildbot logs but that's mostly my preference. I don't think there's a rule for it.
You could add context to these errs messages but still I'm not a fan of errs as a mechanism for reporting this. That's what failure messages are for.
[0] https://github.com/llvm/llvm-project/blob/32541685b2a980290c320adb289b56395a88d4c3/lldb/unittests/Process/Utility/LinuxProcMapsTest.cpp
[1] https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#using-a-predicate-formatter
Also the commit msg " Test case debugging output" should include which test cases, "target parser test cases" would do fine.
Target parser is nominally my area so if you don't have the time to pursue this (these tests don't fail often at all, so I get it) I can have a go at doing what I proposed. Then you can review for me. After all, you're the one adding the CPUs these days so you're seeing the failures.
@DavidSpickett, I would very much appreciate you taking this over, thanks! I needed a way of find out *how* these tests were failing, not just *that* they were failing. I will abandon this change.
clang-format not found in user's PATH; not linting file.