I've found one bug with latest Delphi 10.1 Berlin (and in 10.2 Tokyo too).
If you call TRegEx.Replace with TMatchEvaluator specified, you may got wrong TMatch inside Evaluator function. In Delphi XE-XE5 it seems works good.
Evaluator:
function TForm1.EvaluatorU(const Match: TMatch): string;
var
lChar: Word;
lMatchVal: string;
begin
Result := '';
lMatchVal := Match.Groups[1].Value;
lChar := StrToIntDef('$'+lMatchVal, 0);
if lChar <> 0 then
Result := Char(lChar);
end;
Call:
Result := TRegEx.Replace('\u0418\u0443, \u0427\u0436\u044d\u0446\u0437\u044f\u043d', '\\u([0-9a-f]{4})', EvaluatorU, [roIgnoreCase]);
First call of Evaluator will bring right TMatch.Value (or TMatch.Group[].Value) context, but second call will bring wrong Match.Value to callback function(
Do you have some idea about workaround?
I going to check this issue on TPerlRegEx class, maybe something wrong is in wrapper (TRegEx) functions.
Update: with TPerlRegEx Replacement with callback function (OnReplace) works good...
Update2: it seems there is a bug in TPerlRegEx. It returns wrong GroupOffsets. On First call of OnReplace callback this value is correct. Next calls returns +1 offset more than needed. But call of TPerlRegEx.Groups returns correct subgroup value...
Last update and solution found:
I've found a problem in TPerlRegEx.UTF8IndexToUnicode function optimization. There are LastIndex*/LastIndexResult* fields used to optimize sequential call of function with same params. But after replacement made via callback functions and when MatchAgain is called into TPerlRegEx.ReplaceAll function, this can make a bad trick(
Simple solution is copy System.RegularExpressionsCore.pas from \source\rtl\common to your project directory and replace call of TPerlRegEx.UTF8IndexToUnicode to deprecated unoptimized UTF8IndexToUnicode function... Or clear this internal fields somewhere in ClearStoredGroups function for example.