StringMaker for vector<bool>::reference and vector<bool>::const_reference

[schallerr]

Description

Currently, stringification of a vector<bool>::reference yields "0" and "1" instead of "false" and "true".

For vector<bool>::const_reference, the behavior differs between the STL implementations:
For libc++, it's printed as "0" and "1", while for MSVC and libstdc++, "false" and "true" are printed.

This PR fixes both, so "false" and "true" is printed consistently.

[codecov]

Codecov Report

Merging #2391 (4fad3d2) into devel (81f612c) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##            devel    #2391   +/-   ##
=======================================
  Coverage   91.02%   91.02%           
=======================================
  Files         154      154           
  Lines        7290     7293    +3     
=======================================
+ Hits         6635     6638    +3     
  Misses        655      655           

[horenmar]

So, I don't see an issue with the code, but I have a bigger question: why, and is it worth it?

Generally I don't like adding new specializations to StringMaker that are enabled by default, because it increases the compilation cost of every single assertion -- in fact, if I started from scratch, there would likely be less of them. Given the fact that std::vector<bool> is not used too often, the question has to be whether the specialization is worth it.

[schallerr]

I'm not having a strong opinion about vector<bool>::reference, I just found it nice that it's printed consistently with printing bool.

For vector<bool>::const_reference, however, I'm facing the issue that it's currently inconsistent across standard libraries. While for some it'll print "0/1", for others "false/true".

That's currently happening in practice for #2319, where the approval tests are giving different output for Clang on Mac, so I'm forced to use some replacement for std::vector. I could also add a specialization for StringMaker<vector<bool>::const_reference> to the test itself, but I guess that could in the future lead to ODR violations.

[horenmar]

For #2319 you can put the problematic tests into their own TEST_CASE with the [approvals] tag. We are already doing this for tests that cannot have cross-platform output no matter what we do, e.g. REQUIRE( errno == 0 ) changes between platforms due to errno being a macro.