I recently hit a few cases writing unit tests where the same error is emitted 2+ times by a single API call. I tried adding multiple calls to SetDesiredFailureMsg() with the same VUID, but everything after the first occurrence was still treated as an unexpected error. I'm not sure if this is the expected behavior or not; @chrisforbes was surprised to hear it didn't work, but if this is an intentional restriction, feel free to ignore; I can easily rework the tests to emit multiple errors 1x times apiece.
Details: the messages / message IDs are inserted into a std::unordered_set, and a count is incremented. Adding a duplicate message has no effect on the set contents, but the count is still incremented. The first time the message is encountered, it's removed from the set, causing subsequent appearances to be treated as unexpected errors. If duplicate messages should be allowed, one possibility would be to replace the unordered_set a std::map<ID, count> or similar.
I recently hit a few cases writing unit tests where the same error is emitted 2+ times by a single API call. I tried adding multiple calls to
SetDesiredFailureMsg()
with the same VUID, but everything after the first occurrence was still treated as an unexpected error. I'm not sure if this is the expected behavior or not; @chrisforbes was surprised to hear it didn't work, but if this is an intentional restriction, feel free to ignore; I can easily rework the tests to emit multiple errors 1x times apiece.Details: the messages / message IDs are inserted into a
std::unordered_set
, and a count is incremented. Adding a duplicate message has no effect on the set contents, but the count is still incremented. The first time the message is encountered, it's removed from the set, causing subsequent appearances to be treated as unexpected errors. If duplicate messages should be allowed, one possibility would be to replace the unordered_set astd::map<ID, count>
or similar.