We generally do not even try to pretend to support more than plain ASCII, because doing unicode in old C++ standards is a pain and a half. For `toLower`, we used to wrap `std::tolower` with multiple casts to avoid UB, but calling into it is relatively slow, and it tries to handle different locales, which could cause unexpected results. In addition, the new implementation is significantly faster, which helps speed up the initial process bring up (as comparing tags, and thus test cases is now faster).
The old implementation of String matchers worked by making a, potentially lower-cased, copy of both the constructor arg, and the arg to `match` calls. The new implementation does not make copies, and instead does per-character lowering if needed. This is a win in **most** cases, with two exceptions: 1) Case-insensitive `Equals` between long strings. The old implementation is easy to autovectorize by the compiler, which wins over the extra copy with sufficiently long inputs. 2) Case-insensitive `ContainsSubstring` with inputs that trigger the worst case complexity of O(m*n) of the naive implementation. The latter is fixable with some elbow grease by implementing a proper string search algorithm, but the former is a cost we have to live with.
* Quiet verbosity provides just the test names * Normal verbosity adds tags * High verbosity add the source location of the tests Listing tests with the quiet verbosity results in about 1/4 of the previous output, which leads to measurably faster execution of `catch_discover_tests` when it does not need tags for labels. (If it does need tags, the output is about 1/2 of previous).
As the types and values sent into the writer are determined by Catch2, I do not expect to actually need this support, but it is better to have it and not be surprised in the future.
Closes #3176
The old internals reached into the global hub to stash the allocation(s) for enum value -> string value there, then kept around a potentially invalid (in case the hub was cleaned up) reference into it, going through whole bunch of virtual dispatch in the process. The new internals just store the data in a static variable inside the `StringMaker` specialization. This avoids potential lifetime issues, avoids all virtual dispatch and (almost) reduces the include bloat in the main header path. The reason for (almost) there is that for full include correctness, `EnumInfo` needs `<utility>` include for `std::pair`. However, this brings in things like `std::relops`, because the std headers in C++ are dumb. As this was not included before, and instead we relied on `std::pair` existing in an internal stdlib header that we transitively included, the full include size ends up bigger than before.
Previously the mapping was eager on construction and calls to `next()`. This was fine when generators were always exhausted fully, but with the new generator filtering, we might not want to call the map function eagerly; rather we want to call it only once, after the generator is moved to the target element.