bug#36328: 26.2; Args out of range on search-and-replace of *.cc file

[Juri Linkov]

>> Until this is officially fixed I've come up with the following workaround,
>> going off of the details you provided:
>
>> I created a "replace_fixed.el" file in "~/.emacs.d/lisp/" that is
>> replace.el taken from
>> https://raw.githubusercontent.com/emacs-mirror/emacs/emacs-26/lisp/replace.el
>> with
>> the following diff:
>
>> diff --git a/replace.el b/replace_fixed.el
>> index 08feb8e..8280fdd 100644
>> --- a/replace.el
>> +++ b/replace_fixed.el
>> @@ -2227,7 +2227,7 @@ It is called with three arguments, as if it were
>>             (isearch-forward (not backward))
>>             (isearch-other-end match-beg)
>>             (isearch-error nil))
>> -       (isearch-lazy-highlight-new-loop range-beg range-end))))
>> +       (save-match-data (isearch-lazy-highlight-new-loop range-beg
>> range-end)))))
>
>>  (defun replace-dehighlight ()
>>    (when replace-overlay
>
>> Then I added the following to my "~/.emacs", restarted my emacs server, and
>> the issue was gone!:
>
>> (load-library "~/.emacs.d/lisp/replace_fixed.el")
>
>> This probably isn't the proper fix, but just thought I'd share in case
>> anyone else is experiencing this and wanted a temporary workaround.
>
> Excellent!  To be honest, I was thinking of sending just that workaround
> to you as a temporary patch, but it seems I didn't need to.  :-)
>
> That might well be the fix we end up putting into Emacs, but it might
> not be.  Sorry we're so slow, here.

I think first we should try to narrow down the source of this match data leak.
Then we could decide what is the best solution.  Currently I see no such place
in isearch-lazy-highlight-new-loop that calls external code.  OTOH, while
looking at CC-Mode I noticed that it does some matches on before-change hooks.
I could debug it but can't reproduce neither in 26.1 nor in 27, even with -Q 
-nw.