Julian Müller

I have a draft fix for #5365, but the layout of `_Loop_vals_t` must be changed for it to be reasonably efficient. This means I will have to rename `_Matcher` (and...

> The current strategy for operator== possibly incorrectly behaves if the comparison beyond the index of the first inequivalent iterator pair doesn't have well-defined result (i.e. causes UB, terminates, or...

> We must return the same value as depicted in the Standard, but we may calculate that value in the way we deem to be best for our implementation. Yeah,...

While I can't provide a benchmark, here is a back-of-the-envelope calculation how many more (key) comparisons the algorithm separating key and value comparison is expected to do compared to the...

Vectorization might move the needle the other way in some cases. (But I have to point out that these 50 % are just for the expected case assuming this very...

This also affects `(a?)?`, or potentially any expression containing capture groups quantified with `?`. In such cases, the natural fix also involves disabling the rewriting of `?` in `_Parser::_Quantifier()`. Unfortunately,...

I found a solution: I can actually enable the simple loop optimization even if the loop logic is exerted in the specific case when the subexpression is branchless and all...

> In https://github.com/microsoft/STL/pull/5456 you renamed the matcher to _Matcher2, so (until that ships) I don't think you need to worry about current/past mixing No, this doesn't help because this specific...

As a further small addition, I think we could avoid the virtual function call for the specializations `std::regex` and `std::wregex` by moving the object code of parser and matcher for...

#5403 will remove the only usage of `_Ch_upper`. We can also easily avoid the usage of `_Ch_alpha` because it is used in a context where the ECMAScript grammar only allows...